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

[Ben Pfaff]

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:
> > First, this patch has an aspect of trying a newer interface then falling
> > back to an older one.  I did not read the code carefully enough this
> > time (and do not remember from before) to figure out whether this is
> > likely to be a performance problem with older kernels.  If it is, that
> > might bear some improvement.
> 
> At some point OVS will need to find out in which netns the netdev is.
> It does that by calling  dpif_netlink_vport_from_ofpbuf() which if the
> Kernel API is not supported, then the netdev is considered to be local.
> That doesn't change unless OVS receives a netlink update.
> 
> Then we have two situations. One is when it would fail anyways if the
> netdev is in another netns, but now it seems more clear. It should
> be fast as it is cached.
> 
>     if (netdev_linux_netnsid_is_remote(netdev)) {
>         error = EOPNOTSUPP;
>         goto exit;
>     }    
> 
> 
> The second one is on operations it supports network namespaces like
> get_ifindex(), get_etheraddr(), get_mtu(). But that we rely on cached
> information. Like below:
> 
>     if (!(netdev->cache_valid & VALID_ETHERADDR)) {
>         netdev_linux_update_via_netlink(netdev);
>     }    
> 
> And the cache is invalidated only if the netdev changes. It should
> work even on older kernels for local netdevs. In case of a netlink
> failure, it falls back to the old interface, which also updates
> the cache.
> 
> One interesting case is when you have an old kernel and moved the
> netdev to another netns. Because OVS will try netlink and it will fail
> and then it will try ioctl, which will fail as well and that repeats.
> 
> Probably netlink isn't as fast as a simple ioctl call, but it is
> the preferable interface nowadays and OVS does some level of caching
> already. Perhaps you have specific concerns or some scenarios in mind?

It sounds like my concerns were overblown or inaccurate.  Thank you for
the explanation.

> > 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.