Message-ID: <54D91D0F.9080003@6wind.com>
Date:	Mon, 09 Feb 2015 21:48:15 +0100
From:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	David Ahern <dsahern@...il.com>
CC:	Stephen Hemminger <stephen@...workplumber.org>,
	netdev@...r.kernel.org, roopa <roopa@...ulusnetworks.com>,
	hannes@...essinduktion.org,
	Dinesh Dutt <ddutt@...ulusnetworks.com>,
	Vipin Kumar <vipin@...ulusnetworks.com>
Subject: Re: [RFC PATCH 00/29] net: VRF support

Le 06/02/2015 22:22, Eric W. Biederman a écrit :
>
>
> Having looked at this problem, I am currently convinced that network
> namespaces can be improved to the point where they can reasonably
> act as VRFS.
We are using netns this way at 6WIND.

>
> Further I think code maintenance argues that this VRF proposal is a bad
> direction to go.
>
> David Ahern <dsahern@...il.com> writes:
>
>> On 2/5/15 9:14 PM, Eric W. Biederman wrote:
>>> David Ahern <dsahern@...il.com> writes:
>>>
>>>> On 2/5/15 6:33 PM, Stephen Hemminger wrote:
>>>>> It is still not clear how adding another level of abstraction
>>>>> solves the scaling problem. Is it just because you can have one application
>>>>> connect to multiple VRF's? so you don't need  N routing daemons?
>
>>>> All of those options are rather heavyweight and the number of 'things' is linear
>>>> with the number of VRFs. When multiplied by the number of services needed for a
>>>> full-featured product the end result is a lot of wasted resources.
>>>
>>> If all you want is a single listening socket there are other
>>> implementation possibilities that are focused on solving just that
>>> problem, and would be much more generally applicable.
>>
>> These are examples of the higher level problem -- the current need for
>> replicating processes/threads/sockets per namespace, not to mention the memory
>> consumed by the creation of the namespace itself which is fairly high. i.e., The
>> problem is more than just a listening socket of a single process.
>
> Sometimes replication is simpler and more efficient, so I do not believe
> this is a fundamental design problem.
>
> That said.  Having N listening sockets is arguably a mis-feature of the
> berkely sockets layer, and is fixable by adding support for adding
> features for listening sockets to listen on more than one address.  So
> by adding an feature to teach a listening socket how to listen on
> additional addresses that is fixable.  SCTP and MPTCP have even done
> some work in that area, so it may just be a matter of generalizing
> earlier solutions.  More likely we would want to build on Nicolas
> Dichtels work on adding ids to other network namespaces and have
> our VRF any sockets listen on any network namespace that we an for.
I agree, it would be great to have this kind of feature. Any help to
achieve it is welcomed :)

>
> Similarly we can build on Nicolas Dichtel's work of implementing in
> kernel ids for other network namespaces to provide proc files or
> netlink messages that report on multiple network namespaces at once.
> Assuming of course that such interfaces are shown to be worth
> implementing.
Same here. At least, we should have a try to have a status or to see which
problems can block.

>
> I believe that with small focused changes we can make the existing
> userspace API efficient to work with for programs that want to work
> with multiple network namespaces (or VRFs) at once.
Yes, some work remains into this area.


Regards,
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists