[CC += linux-...@vger.kernel.org]


Since this is a kernel-user-space API change, please CC linux-api@
(and on future iterations of the series). The kernel source file
Documentation/SubmitChecklist notes that all Linux kernel patches that
change userspace interfaces should be CCed to
linux-...@vger.kernel.org, so that the various parties who are
interested in API changes are informed. For further information, see



On Mon, Mar 13, 2017 at 12:44 AM, Hannes Frederic Sowa
<han...@stressinduktion.org> wrote:
> Hi,
> On Sun, 2017-03-12 at 16:26 -0700, David Miller wrote:
>> From: Hannes Frederic Sowa <han...@stressinduktion.org>
>> Date: Mon, 13 Mar 2017 00:01:24 +0100
>> > afnetns behaves like ordinary namespaces: clone, unshare, setns syscalls
>> > can work with afnetns with one limitation: one cannot cross the realm
>> > of a network namespace while changing the afnetns compartement. To get
>> > into a new afnetns in a different net namespace, one must first change
>> > to the net namespace and afterwards switch to the desired afnetns.
>> Please explain why this is useful, who wants this kind of facility,
>> and how it will be used.
> Yes, I have to enhance the cover letter:
> The work behind all this is to provide more dense container hosting.
> Right now we lose performance, because all packets need to be forwarded
> through either a bridge or must be routed until they reach the
> containers. For example, we can't make use of early demuxing for the
> incoming packets. We basically pass the networking stack twice for
> every packet.
> The usage is very much in line with how network namespaces are used
> nowadays:
> ip afnetns add afns-1
> ip address add dev eth0 afnetns afns-1
> ip afnetns exec afns-1 /usr/sbin/httpd
> this spawns a shell where all child processes will only have access to
> the specific ip addresses, even though they do a wildcard bind. Source
> address selection will also use only the ip addresses available to the
> children.
> In some sense it has lots of characteristics like ipvlan, allowing a
> single MAC address to host lots of IP addresses which will end up in
> different namespaces. Unlink ipvlan however, it will also solve the
> problem around duplicate address detection and multiplexing packets to
> the IGMP or MLD state machines.
> The resource consumption in comparison with ordinary namespaces will be
> much lower. All in all, we will have far less networking subsystems to
> cross compared to normal netns solutions.
> Some more information also in the first patch, which adds a
> Documentation.
> Bye,
> Hannes

Michael Kerrisk Linux man-pages maintainer;
Author of "The Linux Programming Interface", http://blog.man7.org/

Reply via email to