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 _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev