[ovs-dev] [PATCH 2/2] datapath: Disable LRO from userspace instead of the kernel.

Jesse Gross jesse at nicira.com
Sat Aug 20 03:39:22 UTC 2011


On Sat, Aug 20, 2011 at 9:50 AM, Justin Pettit <jpettit at nicira.com> wrote:
> On Aug 18, 2011, at 9:22 PM, Jesse Gross wrote:
>
>> The main thing that I was wondering about in this patch is the implications for the backports in RHEL 5. I looked through some of their patches and it appears that they backported LRO (and drivers that enable it) but not the userspace interface (I could be wrong about this though).  If that's the case then this will break on that platform because the userspace request to disable LRO would be ignored.  In that situation, we'd probably need to make the kernel continue to disable LRO on the old kernels. This is still an improvement though because the userspace/kernel expectations are set properly and on those old kernels it would just seem like the NIC doesn't support LRO.
>
> How would you propose handling this?  Putting a RHEL 5 kernel version guard around a call to dev_disable_lro() in vport-netdev.c?

I first double checked and RHEL 5 definitely doesn't have the ethtool
ops (in order to maintain interfaces) and instead uses a completely
different mechanism for this, so we have to call dev_disable_lro().

So, yes, I think what you're describing is right.  Probably I would
just check to see if the kernel version is less than 2.6.24 and call
dev_disable_lro(), in the non-RHEL case this will just evaluate to a
no-op anyways.

The final piece that I just thought of, is the relationship of the MTU
check in vport_send() and skb_warn_if_lro().  The former will catch
hardware LRO and interfaces with mismatched MTU and the later the
deprecated (but still extant software LRO, precursor to GRO).  When
disabling LRO, we will turn off both the software and hardware
versions so there is some overlap.  The checks are useful but they'll
trigger warnings if we start using LRO.  That's not strictly a
backwards compatibility problem but it will still create a little bit
of a versioning mess.  What if we just move all of them to
netdev_send(), which is where they are actually useful?

I guess all of this stuff is a little messier than I thought at first...



More information about the dev mailing list