Bug 616841 - RFE: Support setting of rx, tx, sg, tso, ufo, gso, gro, lro against physical network interfaces
Summary: RFE: Support setting of rx, tx, sg, tso, ufo, gso, gro, lro against physical ...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt   
(Show other bugs)
Version: 7.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-21 14:16 UTC by Daniel Berrange
Modified: 2013-01-23 19:57 UTC (History)
15 users (show)

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

Attachments (Terms of Use)

Description Daniel Berrange 2010-07-21 14:16:20 UTC
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:
      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):

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 14:19:44 UTC
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 19:06:35 UTC
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 16:07:04 UTC
Michal, if we take the udev route, what would the design look like?

Comment 10 Laine Stump 2013-01-23 19:43:16 UTC
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.