Hi,
currently, ovs switches LRO off in user space:
commit 24b019f808211a95078efd916064af0975ca5733
Author: Justin Pettit <jpet...@nicira.com>
Date: Fri Aug 26 23:34:40 2011 -0700
datapath: Disable LRO from userspace instead of the kernel.
Whenever a port is added to the datapath, LRO is automatically disabled.
In the future, we may want to enable LRO in some circumstances, so have
userspace disable LRO through the ethtool ioctls.
As part of this change, the MTU and LRO checks are moved to
netdev-vport's send(), which is where they're actually needed.
Feature #6810
However, this is done on the interface that's being added. If the
interface is vlan, LRO should be disabled on the underlying interface
instead (recursively), similarly to what dev_disable_lro in the kernel
does.
However much dubious adding of a vlan interface to ovs bridge is, it's
unfortunately being seen in the wild. The possible solutions are:
1. Using netlink, obtain IFLA_LINK recursively in
dpif_netlink_port_add__. Quite a lot of code needed, it seems.
2. Just call dev_disable_lro in the kernel.
The latter is much easier and less error prone (no problems with
cross-netns vlan links, for example). The commit quoted above suggests
that LRO may be left enabled in some cases, though.
I can't imagine a case where it would be useful and it haven't actually
happened in the past 4 years. Any objections to me implementing the
option #2? Or do we really need to do #1? (And in that case, what to do
with cross-netns vlans? Use the new netnsid infrastructure and switch
netns while traversing the links?)
Thanks,
Jiri
--
Jiri Benc
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
