On Thu, Feb 07, 2013 at 17:41 +0000, Stuart Henderson wrote: > At least the following vr(4) devices can be configured to permit > larger MTUs. > > vr0 at pci0 dev 18 function 0 "VIA RhineII-2" rev 0x51: irq 11, address > 00:40:63:c0:5d:27 > vr1 at pci2 dev 0 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address > 00:00:24:cd:72:30 > > This is extremely useful as it permits carrying stacked vlans > on Alix/net5501, and also permits carrying 1500 MTU packets within > pppoe(4) using the RFC4638 support. > > As seems to be common for fast ethernet chips, the register to set > the length is 11 bits. When tested, both these NICs performed > stably with an MTU of 1748 (around 95Mb/s throughput on my test > machine, dmesg below); with a slightly higher MTU things mostly > still worked however throughput fluctuated; with a much higher > MTU connections stalled. > > As I am unsure about the effects on the other ICs supported by > this driver, and because the Rx length is programmed whether or not > the mtu is actually raised, I have added a quirk so this is only > attempted on the "newer" ICs. (in quotes because my RHINEII_2 is > on a ~10 year old VIA EPIA board). > > Tests so far have included use of vlan/svlan and NFS. > > Any comments or additional test reports? (of course I am primarily > interested in reports of any change to *existing* behaviour, tests > of new support is a bonus but is less interesting). Any OKs even, > or is it a bit close to release for this? >
works here on net5501. i'm in favor of this diff going in now.
