On 2014/08/21 08:45, Chris Cappuccio wrote: > Stuart Henderson [st...@openbsd.org] wrote: > > On 2014/08/20 17:17, Chris Cappuccio wrote: > > > David Gwynne [da...@gwynne.id.au] 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.. > > that said, there is a clear use case for being able to do 1500 MTU packets > > untagged while using jumbos on a vlan... > > Yeah >
