Stuart Henderson [[email protected]] wrote: > On 2014/08/21 08:45, Chris Cappuccio wrote: > > Stuart Henderson [[email protected]] wrote: > > > On 2014/08/20 17:17, Chris Cappuccio wrote: > > > > David Gwynne [[email protected]] wrote: > > > > > sthen@ says this is likely a bit optimistic. while most of our > > > > > drivers unconditionally configure their max mru, there's some stupid > > > > > ones that still interpret the configured mtu as a what the mru should > > > > > be. > > > > > > > > > > > > > All the more reason to make this change, I'd say :) > > > > > > it's not just that - there are some like et(4) with obvious trade-offs > > > visible > > > in the driver source code which are only wanted in the case where jumbos > > > are > > > actually in use. and who knows what various chips will do internally when > > > the > > > command to permit jumbos or raise the valid packet size is sent. > > > > > > > I don't think this is relevant. If a chip or driver is buggy in the jumbo > > MTU > > non-vlan case, now it will be buggy in the (somewhat unique) vlan jumbo MTU > > case as well.... > > Oh I was thinking of the case where we changed those drivers to fix things > so that the "1500 MTU untagged / high MTU tagged" state worked which would > involve downsides for non-jumbo. If you don't care if the new support > actually works on some chips then that wouldn't apply.. >
Well in the case of if_et, the change the dlg proposes in if_vlan would not make a difference to the if_et behavior at all. My first glance at et says hardmtu == mtu
