Bug 616841 - RFE: Support setting of rx, tx, sg, tso, ufo, gso, gro, lro against physical network interfaces
RFE: Support setting of rx, tx, sg, tso, ufo, gso, gro, lro against physical ...
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-21 10:16 EDT by Daniel Berrange
Modified: 2013-01-23 14:57 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-23 14:51:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2010-07-21 10:16:20 EDT
Description of problem:
Large receive offload is a feature that isn't supported by Linux bridges, nor virtio backend drivers. If a physical NIC has LRO enabled by default, you'll get dropped packets on the host

eth3: received packets cannot be forwarded while LRO is enabled
eth3: received packets cannot be forwarded while LRO is enabled
eth3: received packets cannot be forwarded while LRO is enabled

Thus we need to be able to disable LRO on physical NICs.

The ifcfg-xxx files appears to support these settings, albeit with a deprecated option

   Deprecated, but supported:
    ETHTOOL_OPTS=...
      Any device-specific options supported by ethtool. For example,
      if you wanted to force 100Mb full duplex:
        ETHTOOL_OPTS="speed 100 duplex full autoneg off"
      Note that changing speed or duplex settings almost always
      requires disabling autonegotiation with 'autoneg off'.

      Long term, this should be done by sysadmin-written udev rules.

So we have two options

 - Expose this tunable via the interface XML (and by extension netcf) and use the deprecated setting
 - Expose this tunable via the node device APIs and create udev rules

We likely need to expose whether each physical NIC is capable of gro, lro, etc via the node device APIs in any case, otherwise you won't know whether the tunable is actually supported on the NIC in question.

This could push the balance in favour of a pure nodedevice API instead of nodedev + interface

Version-Release number of selected component (if applicable):
libvirt-0.8.2

How reproducible:
Hardware dependant

Steps to Reproduce:
1. Get a machine witha NIC supporting LRO
2. Enable LRO
3. Put the NIC into a bridge
4. Boot a guest with the bridge
5. Observe dropped packets
  
Actual results:


Expected results:


Additional info:
Comment 1 Michael S. Tsirkin 2010-07-21 10:19:44 EDT
some notes: an additional idea is to make libvirt verify that NIC is
compatible with virt, and give the admin hints if it is not.
Comment 5 Laine Stump 2011-10-13 15:06:35 EDT
Bug 743176 points out another problem with having LRO turned on on a physical ethernet - when ip_forward is enabled, the device will be reset.
Comment 7 Dave Allan 2011-12-22 11:07:04 EST
Michal, if we take the udev route, what would the design look like?
Comment 10 Laine Stump 2013-01-23 14:43:16 EST
Investigating down a rat hole of BZs, I've found that this has been remedied in the RHEL6 kernel as of 2.6.32-230 (See Bug 772317). The fix is to notice that LRO is turned on when attaching a netdev to a bridge or bond (neither of which support LRO), and simply disable it at that time. This makes perfect sense, since there is no possible reason that having it enabled would be desired.

Upstream uses a different mechanism, but the result is the same - if LRO should be disabled for a particular device due to it being attached to some other driver that doesn't support LRO, then it will be automatically disabled.

This all means that there is no longer any need for libvirt to provide a mechanism for enabling/disabling LRO, so I'm closing this BZ.

Note You need to log in before you can comment on or make changes to this bug.