[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CA7A07C.5030504@free.fr>
Date: Sat, 02 Oct 2010 23:13:32 +0200
From: Daniel Lezcano <daniel.lezcano@...e.fr>
To: Pavel Emelyanov <xemul@...allels.com>
CC: hadi@...erus.ca, "Eric W. Biederman" <ebiederm@...ssion.com>,
linux-kernel@...r.kernel.org,
Linux Containers <containers@...ts.osdl.org>,
netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Michael Kerrisk <mtk.manpages@...il.com>,
Ulrich Drepper <drepper@...il.com>,
Al Viro <viro@...IV.linux.org.uk>,
David Miller <davem@...emloft.net>,
"Serge E. Hallyn" <serge@...lyn.com>,
Pavel Emelyanov <xemul@...nvz.org>,
Ben Greear <greearb@...delatech.com>,
Matt Helsley <matthltc@...ibm.com>,
Jonathan Corbet <corbet@....net>,
Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
Jan Engelhardt <jengelh@...ozas.de>,
Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCH 8/8] net: Implement socketat.
On 09/23/2010 01:53 PM, Pavel Emelyanov wrote:
> On 09/23/2010 03:40 PM, jamal wrote:
>
>> On Thu, 2010-09-23 at 15:33 +0400, Pavel Emelyanov wrote:
>>
>>
>>> This particular usecase is unneeded once you have the "enter" ability.
>>>
>> Is that cheaper from a syscall count/cost?
>>
> Why does it matter? You told, that the usage scenario was to
> add routes to container. If I do 2 syscalls instead of 1, is
> it THAT worse?
>
>
>> i.e do I have to enter every time i want to write/read this fd?
>>
> No - you enter once, create a socket and do whatever you need
> withing the enterned namespace.
>
Just to clarify this point. You enter the namespace, create the socket
and go back to the initial namespace (or create a new one). Further
operations can be made against this fd because it is the network
namespace stored in the sock struct which is used, not the current
process network namespace which is used at the socket creation only.
We can actually already do that by unsharing and then create a socket.
This socket will pin the namespace and can be used as a control socket
for the namespace (assuming the socket domain will be ok for all the
operations).
Jamal, I don't know what kind of application you want to use but if I
assume you want to create a process controlling 1024 netns, let's try to
identificate what happen with setns and with socketat :
With setns:
* open /proc/self/ns/net (1)
* unshare the netns
* open /proc/self/ns/net (2)
* setns (1)
* create a virtual network device
* move the virtual device to (2) (using the set netns by fd)
* unshare the netns
...
With socketat:
* open a socket (1)
* unshare the netns
* open a netlink with socketat(1) => (2)
* create a virtual device using (2) (at this point it is init_net_ns)
* move the virtual device to the current netns (using the set netns
by pid)
* open a socket (3)
* unshare the netns
...
We have the same number of file descriptors kept opened. Except, with
setns we can bind mount the directory somewhere, that will pin the
namespace and then we can close the /proc/self/ns/net file descriptors
and reopen them later.
If your application has to do a lot of specific network processing,
during its life cycle, in different namespaces, the socketat syscall
will be better because it will reduce the number of syscalls but at the
cost of keeping the file descriptors opened (potentially a big number).
Otherwise, setns should fit your needs.
>> How does poll/select work in that enter scenario?
>>
> Just like it used to before the enter.
>
>
>> cheers,
>> jamal
>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists