On Sat, Aug 20, 2011 at 9:50 AM, Justin Pettit <jpet...@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... _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
