[ovs-dev] [PATCH v4 0/6] Add minimum network namespace support.

[Flavio Leitner]

On Wed, Apr 04, 2018 at 10:07:08AM -0700, Ben Pfaff wrote:
> On Tue, Apr 03, 2018 at 09:48:55PM -0300, Flavio Leitner wrote:
> > On Sat, Mar 31, 2018 at 01:23:20PM -0700, Ben Pfaff wrote:
> > > Second, I think that it is possible to open a Netlink socket for a
> > > particular namespace, which might provide a way to do arbitrary Netlink
> > > operations in a namespace even if the API doesn't support a namespace ID
> > > as a parameter.
> > 
> > That wasn't really possible before the new APIs we have now.
> 
> I was thinking of something like "create a new thread, setns() to the
> namespace of interest, create a Netlink socket, make the fd of the
> socket known to the rest of the process".  It is pretty heavyweight
> though and I don't know the level of practicality.  Maybe the "new
> thread" part isn't necessary, I dunno.

You're not the only one thinking on that solution, believe me. :)
However, it's not that simple, or even possible because when
the interface is moved to another netns, the only thing OVS receives
is a device de-registration event from the kernel, like if it's
gone forever.

At that point, OVS can't really tell if the netdev was just destroyed
or moved, even less to which netns it was moved to.

We can rely on listening to all netns using one of the "new" API
extensions.  That allows OVS to listen on all child netns. So,
it would receive a de-registration in the local one, and a
registration on a target one (and only if a netnsid is assigned).

However, that alone isn't enough (races) and the netnsid doesn't
necessarily map to a file in the local fs. The netns directory
might not even be mounted or mounted somewhere else. If we assume
it's there, we still need a "new" API from 2015 to translate fd
to netnsid. And what happens if the interface moves again? The
netnsid is only valid within its namespace.

So, unless you use the newest APIs, it doesn't sound possible to
implement that solution. Even if you use them, it most probably
won't be reliable with what we have today.

This patchset brings enough support to keep existing use cases
working so that we can improve/fix others.  For instance I recently
pushed a patch to not send packets to a TAP device when it is DOWN.
I think the correct would be to fix at xlate layer for all types
of ports, but I couldn't do it or it would break internal ports
in another netns because OVS couldn't get its current state.

I agree when you said there will be missing APIs, so I think for
use cases using networking namespaces, we should recommend using
veth pairs instead which resolves, in a more robust way, those
issues and many more with little or no performance impact.

-- 
Flavio