Date: Wed, 15 Jan 2014 14:53:08 +0000 From: Joe Holden <lists@rewt.org.uk> To: Garrett Wollman <wollman@bimajority.org>, freebsd-net@freebsd.org Subject: Re: ETHER_MAX_LEN_JUMBO Message-ID: <52D6A0D4.1060304@rewt.org.uk> In-Reply-To: <20140108033959.GX99167@funkthat.com> References: <21196.29430.733181.353677@hergotha.csail.mit.edu> <52CC9EF0.5010504@rewt.org.uk> <20140108012215.GV99167@funkthat.com> <52CCAA85.60107@rewt.org.uk> <20140108033959.GX99167@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/01/2014 03:40, John-Mark Gurney wrote: > 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... > Looks like the only driver that relies on a fixed frame length for jumbos is cas, but that could easily be changed into a define just for that driver, the others (cxgb/cxgbe/mxge) just use it as either a default mtu or as an upper limit (which should really be based on the chip, not an arbitary limit)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52D6A0D4.1060304>