Bug 697342

Summary: let control device's LRO
Product: Red Hat Enterprise Linux 5 Reporter: Dan Kenigsberg <danken>
Component: ethtoolAssignee: Andy Gospodarek <agospoda>
Status: CLOSED NOTABUG QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.6CC: agospoda, peterm
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-11 14:34:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 692093    

Description Dan Kenigsberg 2011-04-17 22:39:14 UTC
Description of problem:
Unlike RHEL6's 2:ethtool-2.6.33, RHEL5's ethtool-6-4 is ignorant of Large Receive Offload. Being unable to disable LRO, makes nics with LRO support unusable for RHEV-controlled VMs with VLANs.

I'd be happier if LRO is disabled by kernel as requested in bug 696374. But if that does not come through, we'd need a means to disable LRO on RHEV-controlled nics.

Version-Release number of selected component (if applicable):
ethtool-6-4

Comment 1 Andy Gospodarek 2011-05-10 18:33:17 UTC
This should already be fixed.  Great effort was made in RHEV to disable LRO whenever a device was put into forwarding mode.

Are you seeing this fail with a specific physical device or stacked devices (like VLANs) in bug 696374.

Comment 2 Dan Kenigsberg 2011-05-11 10:47:47 UTC
I've opened this feature request only as a fallback, if the kernel bug is not resolved in time. If and when bug 696374 is solved, RHEV would loose its interest in this feature request, though being able to manually control LRO could be cool.

Comment 3 Andy Gospodarek 2011-05-11 14:34:52 UTC
Since adding ethtool support to disable LRO would be a kABI breaker as it exists upstream (and since I'm pretty confident that bug 696374 is going to be resolved) I'm going to close this as NOTABUG.

Comment 4 Dan Kenigsberg 2011-05-12 11:57:30 UTC
If bug 696374 is solved, this would not be a bug, as well as vdsm bug 692093... But that is not yet the case.. so I'm keeping my bug open until basic ack from djuran.