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

[Flavio Leitner]

On Sat, Mar 31, 2018 at 01:23:20PM -0700, Ben Pfaff wrote:
> On Thu, Mar 29, 2018 at 11:05:25PM -0300, Flavio Leitner wrote:
> > Today Open vSwitch doesn't know about network namespaces (netns), but
> > users are moving internal ports to other namespaces.  Although packets
> > are still flowing, the daemon fails to find out basic port information,
> > like if it is UP or DOWN, for instance.
> > 
> > This patchset rely on a new kernel vport API recently accepted to find
> > out the new network namespace ID of a bridge's port. This information
> > along with the port's name recorded in the database is used to match the
> > corresponding netlink messages.
> > 
> > This patchset also leverages another kernel API that allows the daemon
> > to listen to all netlink messages from all netns which has an ID assigned
> > into it.  This and the previous change allows the userspace to track ports
> > in other network namespaces.
> > 
> > If any of the APIs aren't available, it falls back to the older APIs to
> > not break backwards compatibility.
> 
> I applied this to master.  Thank you!
> 
> I have a request: please submit a patch to add something to NEWS to
> explain the new features.

Will do.

> I also have some further thoughts.
> 
> 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?

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

-- 
Flavio