On Fri, Apr 06, 2018 at 04:42:34PM -0300, Flavio Leitner wrote: > 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.
Thank you for educating me. It is informative. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev