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")
.... *why* is it necessary to do that?
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).
(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.
What network driver are you using?
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).
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!
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.
Based on comment #8 from reporter, closing this as current release.