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

Reply via email to