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

Ben Pfaff blp at ovn.org
Thu Feb 1 22:42:10 UTC 2018


On Fri, Jan 26, 2018 at 04:23:44PM -0200, Flavio Leitner wrote:
> Hi Ben,
> 
> 
> On Wed, Jan 10, 2018 at 04:07:38PM -0800, Ben Pfaff wrote:
> > Thanks for the series.  I actually think that it's pretty close.  For
> > me, this series falls into the category of "obviously the right
> > direction but impossible to fully validate before applying it".  It
> > builds fine and I was about to push it when I realized that it breaks
> > most of the unit tests with failures like:
> > 
> >     --- /dev/null   2017-07-26 15:46:07.674034656 -0700
> >     +++ /home/blp/nicira/ovs/_build/tests/testsuite.dir/at-groups/3/stdout  2018-01-10 16:03:35.309361001 -0800
> >     @@ -0,0 +1 @@
> >     +2018-01-11T00:03:35Z|00007|dpif_netlink|WARN|Generic Netlink family 'ovs_datapath' does not exist. The Open vSwitch kernel module is probably not loaded.
> > 
> > The unit tests are supposed to work without the kernel module loaded (I
> > run them on a system that doesn't even have the module).  Previously
> > they didn't even try to interact with the kernel module and now clearly
> > they do.  Can you figure out how that changed?  It would be best to fix
> > it.
> 
> 
> When bridge is running, it will try to initialize the routing table
> and for that it will try get interface's flags (lo, NICs), or the addr
> list.  Both interfaces are now using netlink messages to find out if the
> interface is in the local network namespace or not[1] and that's when the
> netlink is initialized. If you don't have the module, the warn message
> is printed.
> 
> This patchset relies on netlink messages anyways to keep track of the
> interfaces, so it is preferred. It falls back to the old interfaces
> only if the kernel is not recent enough though.
> 
> One possible way to fix this is to try the old interface first and fall
> back to netlink only if that fails.  That's not ideal because we would
> need to keep track of return codes indicating the device is not in the
> local network namespace, or blindly try it again.  Another thing to
> consider is that we might be able to remove the old interface and only
> use netlink in the future to simplify the code.
> 
> It doesn't sound like a good idea to remove that message as it has value.
> 
> I can fix the testsuite vswitchd initialization to ignore that message,
> but after each test is completed, the testsuite checks for WARN messages
> and fails if there is one in the logs.
> 
> Ben, any thoughts? I don't know how bad it is to add a dependency to
> openvswitch module to decide whether the patchset must address that or
> if it's okay to fix the testsuite.
> 
> 
> [1] 
> netdev_linux_netnsid_is_remote
>  +- netdev_linux_netnsid_update__
>   +- dpif_netlink_vport_get
>     (this uses openvswitch's  vport get cmd)

I see the following possibilities here.

* Do something to keep the code from trying to load the module.  It
  sounds like this is difficult or undesirable.

* Remove the message.  It has value since when it shows up in logs I can
  tell the user that's the problem.

* Downgrade the message to INFO level.  Maybe that is the right solution
  since now it's going to appear even if the user doesn't really need
  it, making it not anything to really warn about anymore.

* Ignore this message, too, in check_logs in tests/ofproto-macros.at.

* Downgrade the message to DBG level at the current point it's issued,
  but then issue it at WARN level later in dpif_netlink_open() since
  that's the place where it's clear that the user is trying to use
  something that's unavailable.



More information about the dev mailing list