[ovs-dev] LRO disabling not working correctly

Jesse Gross jesse at nicira.com
Thu May 21 21:19:11 UTC 2015


On Thu, May 21, 2015 at 10:37 AM, Jiri Benc <jbenc at redhat.com> wrote:
> Hi,
>
> currently, ovs switches LRO off in user space:
>
> commit 24b019f808211a95078efd916064af0975ca5733
> Author: Justin Pettit <jpettit at 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?)

I can at least give you the background on why it was done this way originally:

The general reason to disable LRO is for packets that traverse to
another host (either VM or physical) that might get upset about packet
modifications as LRO does not preserve packets in the way that GRO
does. Obviously bridges are usually meant to connect hosts, so they
disable LRO.

However, OVS is commonly used to only connect the NIC to the local
host in the case of tunnels. The idea was that OVS userspace could
detect this situation and not disable LRO since it isn't doing any
real bridging. And in the case of bonds, you would still be able to do
this optimization because userspace would know that traffic is never
forwarded between physical ports, whereas the kernel doesn't know
this.

Obviously this hasn't actually been implemented in 4+ years but that
was the rationale and it does seem like it still applies today.



More information about the dev mailing list