Proposal: libnetwork support for adding physical interfaces into container sandbox

[sainath14]

Is there native libnetwork support for adding physical eth interfaces into sandbox?

[aboch]

No. Addition was recently proposed in #1003

[sanimej]

The proposal in #1003 was to add the physical interface to the bridge in the host namesapce. The request here is to add it to a sandbox/container namespace.

@sainath14 What use cause are you trying to accomplish with this ? Typically physical interfaces are shared by all containers and not tied to one particular container.

[sainath14]

yes #1003 handles a different scenario.

Enabling physical interfaces into sandbox, we can look at the following usecases/benefits

1. Server configurations have multiple NICs. Certain container (container demanding high network performance) can be assigned a NIC and get the entire bandwidth of the interface instead of sharing the bandwidth of the adapter with other containers.
2. Server NIC configuration has SR-IOv. SR-IOv exposes the same physical NIC as multiple NICs to OS and application stack. Typical configuration could support 64 virtual functions. When containers use these physical interfaces, they can ping on underlay network (easing the complexity of vxlan/bridge management in large virtual networks). This also offloads the cpu from any additional processing involved for packet encapsulation and decapsulation.
3. Also provides flexibility to use SR-IOv virtual functions in place of software macvlan devices. In certian load scenarios, hardware based SR-IOv VFs can provide better bandwidth between containers compared to macvlan, especially when CPU is overloaded.

Comments are appreciated.

[sainath14]

@mavenugo I saw this PR is referenced to in #1003 and that code freeze in place now for docker release. May I know when is the subsequent docker release so that I can plan accordingly?

[dreamcat4]

Whenever it may happen, please also consider to fix bug #211411.

[sainath14]

A nice blog on SR-IOv and SR-IOv NIC
http://blog.scottlowe.org/2009/12/02/what-is-sr-iov/

As part of this proposal, one of the usecases is to support a intrahost network created from sr-iov virtual interfaces inside the container sandbox. Network create command can look like below

docker create network -d vfnet --subnet=192.168.1.0/24 --gateway=192.168.1.1 -o parent=bus.dev.func vfnet100

This would let containers join into the network vfnet100 with the interfaces derived from Virtual functions (VFs) from the physical function (PF) device with bus.dev.func

Comments are appreciated on the idea and also specifically on the docker create network command options

[deathspeeder]

Support needed too!
For SR-IOV, VF can be assigned to container by pipework from http://jason.digitalinertia.net/exposing-docker-containers-with-sr-iov/ However, it first need to start container and then invoke pipework script. If directly physical interfaces is supported things can be easier.

[oblazek]

Any update on this proposal? Like @deathspeeder I have been using pipework and that was the only simple way. This would make a huge difference.