Bug 465797 - Using large (>1500) MTU inside XEN domU
Using large (>1500) MTU inside XEN domU
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Herbert Xu
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-06 09:38 EDT by Nenad Opsenica
Modified: 2008-10-13 10:25 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-13 10:25:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
add RAW_ETHTOOL_OPTS option to ifcfg-* files (1.39 KB, patch)
2008-10-06 09:38 EDT, Nenad Opsenica
no flags Details | Diff

  None (edit)
Description Nenad Opsenica 2008-10-06 09:38:24 EDT
Created attachment 319554 [details]
add RAW_ETHTOOL_OPTS option to ifcfg-* files

Description of problem:

To be able to reliably use interfaces with MTU>1500 inside domU, it is necessary to turn off tcp segmentation offload using ethtool.

Attached patch adds not_very_elegant RAW_ETHTOOL_OPTS ifcfg-* option, which is useful for setting up this parameter (e.g. RAW_ETHTOOL_OPTS="-K $DEVICE tso off")
Comment 1 Bill Nottingham 2008-10-07 10:40:01 EDT
.... *why* is it necessary to do that?
Comment 2 Nenad Opsenica 2008-10-07 18:32:42 EDT
My case: dom0 uses gigabit ethernet interfaces; XEN uses bridged interface configuration. In order to maximize throughput, MTU on eth interface in dom0 should be > 1500, so bridge interface and domU eth interface must use the same MTU.

By default, TCP segmentation offloading is turned on on large frames. There is 
no TCP offloading engine in domU "network hardware" and without turning off TSO, it is not possible to establish any TCP connection (CRC errors).
Comment 3 Bill Nottingham 2008-10-07 20:54:27 EDT
(In reply to comment #2)
> By default, TCP segmentation offloading is turned on on large frames. There is 
> no TCP offloading engine in domU "network hardware" and without turning off
> TSO, it is not possible to establish any TCP connection (CRC errors).

This smells like a kernel bug (either in the driver or network layer) - it shouldn't be running by default in a way that eats packets.
Comment 5 Herbert Xu 2008-10-08 07:18:30 EDT
What network driver are you using?
Comment 6 Nenad Opsenica 2008-10-09 09:17:05 EDT
Driver for one eth card is e1000.
The second card is VIA Velocity, I'm using "velocityget" driver (VIA supplied), as kernel "via-velocity" has some issues (it was long time ago that I checked, I really can't remeber what were the problems, but something with jumbo frames support and reliability).
Comment 7 Herbert Xu 2008-10-09 10:47:59 EDT
So exactly which one is it that's having problems with Xen? Also what do you mean by CRC errors? If you mean checksum errors please attach the tcpdump from both within dom0 and from a physical machine other than the one where you're running Xen showing the packet data with the -x option.  Thanks!
Comment 8 Nenad Opsenica 2008-10-13 09:39:18 EDT
Huh, in the meantime, problem has disappeared :)
As far as I can recall, I had this problem one year ago, and found that TSO setting was the cause.
With software packages I use today (kernel-xen-2.6.18-92.1.13.el5), everything is working just fine. 
Sorry for bothering.
Comment 9 Bill Burns 2008-10-13 10:25:37 EDT
Based on comment #8 from reporter, closing this as current release.

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