Date: Tue, 7 Jan 2014 19:40:00 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Joe Holden <lists@rewt.org.uk> Cc: freebsd-net@freebsd.org, Garrett Wollman <wollman@bimajority.org> Subject: Re: ETHER_MAX_LEN_JUMBO Message-ID: <20140108033959.GX99167@funkthat.com> In-Reply-To: <52CCAA85.60107@rewt.org.uk> References: <21196.29430.733181.353677@hergotha.csail.mit.edu> <52CC9EF0.5010504@rewt.org.uk> <20140108012215.GV99167@funkthat.com> <52CCAA85.60107@rewt.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Joe Holden wrote this message on Wed, Jan 08, 2014 at 01:31 +0000: > On 08/01/2014 01:22, John-Mark Gurney wrote: > >Joe Holden wrote this message on Wed, Jan 08, 2014 at 00:42 +0000: > >>16k frames are available on commidity intel cards so perhaps a bump to > >>16k should be enough for the foreseeable future, although saying that > >>there is nothing to stop another big leap in frame sizes. > >> > >>We should probably be ahead of the curve here, rather than playing catch > >>up with vendors. Would it be possible to limit the max size by looking > >>at drivers in the tree at compile-time, perhaps have them declare the > >>max frame size the supported hardware can handle? > > > >Why do we even need this define? > > > >atse uses it to create a buffer so it doesn't have to deal w/ data being > >split between mbufs... why they didn't use m_copydata + the ofset, I > >don't know, but shouldn't be hard to fix the driver.. > > > >cas uses it instead of reading what the interface MTU is when programming > >the max length of a frame... > > > >ng_eiface just uses it to limit how large you can set your MTU... > > > >It is used to define ETHERMTU_JUMBO, which is used by a few drivers > >(cas, cxgb, cxgbe and mxge) to either set the default mtu, or limit how > >large the MTU can be set to... > > > >I would say we should just remove these defines... If a card has an > >MTU limit, let it define it's own, not use some fake limit by the rest > >of the system... > > > This sounds like a much better idea if it isn't limited by the stack > architecture, if it is only a handful of drivers that even care then the > obviously correct solution is to remove this define entirely. I used fxr.watson.org to do this research: http://fxr.watson.org/fxr/ident?i=ETHER_MAX_LEN_JUMBO Just so you can browse around for yourself. :) Hmm.. to make matters more interesting, the kernel version of cxgb does not default to jumbo frames, BUT, the module version of cxgb does default.. It's probably because no one uses the module that no one noticed the difference... If you need help generating patches, let me know.. I can commit them once they are tested, but I don't have hardware to test myself... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140108033959.GX99167>