https://bugzilla.novell.com/show_bug.cgi?id=244799 Summary: network interfaces don't choose proper MTU on direct connect hosts Product: openSUSE 10.2 Version: Final Platform: i686 OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Network AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: suse@tlinx.org QAContact: qa@suse.de Context of problem: I will "admit" this could be considered a request for an enhancement. However, I feel the current behavior violates 'least surprise' and is due to a bug in software. If I plug 10Mb or 100Mb hardware onto an ethernet that supports 1Gb, they "just work" -- transparently. It may be the switches that do the auto filtering, not sure, but I am able to plug in a mixture of 10/100/1G devices onto a net that supports the highest speed. The same isn't true of devices that support larger packet sizes under GbE (I don't know of any slower devices that speak "jumbo" packets; packets usually ranging up to 9000 bytes instead of the standard 1500). Specific examples/descriptions: With GbE, I have some hosts that support 6000B MTU's, one with 9000B, and most with a standard 1500B MTU (note: the 6000B MTU is used by inexpensive Netgear cards, while the 9000B packets are supported on an Intel card; there are lists on the internet of cards supporting 9k or greater packet sizes. It isn't generally recommended to use packet sizes >9k as it is most common *and* because the 32-bit CRC used for ethernet packets on the link becomes less reliable with packet sizes over ~11,400 bytes. If I set two hosts' (say a 6k and 9k) to the same MTU (6000), they interact correctly, BUT, as soon as one of them tries to speak to a 1500B MTU host, any packets over 1500B are dropped. The fault doesn't correct even though I have my systems configured to do MTU discovery. Small packets between interfaces supporting different MTU's work correctly (like a login session usually continues working without a problem). But any transfers that might make use of the larger packets (file transfers) just get silently dropped. Software problem: It _appears_ that most software treats the MTU as a property of the media -- i.e. the used MTU is the maximum MTU set in "ifconfig" for a specific interface. In reality, the MTU is a property of two directly communicating MAC's (as filtered through switches). Suggested solution: I'd suggest probing the MTU size *asynchronously* -- so as not to delay initial communications. But I'd probe the MTU size supported from my local host to any directly accessible (or seen) MAC address. I'd then store MTU sizes on a per-MAC basis and expire the MTU's in the same way I would stale MAC entries. Two MACs, I believe, cannot directly communicate through a router -> the router provides the next "hop" (or MAC) that would be probed for jumbo support. As switches (and hubs) strive to be mostly invisible, MACs seen through a switch would be treated as directly connected. However, of note is the fact that the MTU for a given MAC, while constant for my local host (assuming the MAC isn't moved to a different network segment in the middle of a session; thus the reason for aging both MAC and MTU together), a different host separated by a different switch might see the MTU differently depending on that packet sizes the intervening switch supports). In initial tests, increasing packet sizes from 1500->6000 increased transfer speeds by 100-200% (from 300-400Mb up to near 600-700Mb) with a drop in cpu usage. On 10GbE, one would expect to see further differences. This is likely something that would have to go into the kernel... I'll understand if severity is changed to "RFE", but I wanted to set it as major, since the impact on performance is large (and when different packet sizes are attempted, the user will get what appear to be semi-random failures -- but only when packet sizes >1500 (or whatever the min MTU of the pair is). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.