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)
fbl
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
