Date: Wed, 08 Jan 2014 01:31:49 +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: <52CCAA85.60107@rewt.org.uk> In-Reply-To: <20140108012215.GV99167@funkthat.com> References: <21196.29430.733181.353677@hergotha.csail.mit.edu> <52CC9EF0.5010504@rewt.org.uk> <20140108012215.GV99167@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >> On 07/01/2014 21:34, Garrett Wollman wrote: >>> In <net/ethernet.h>, the constant ETHER_MAX_LEN_JUMBO is set to 9018. >>> According to svn, this was added by sam back in 2002, and now seems a >>> bit low. Our maximum MTU at work has always been 9120 (implying 9138 >>> for ETHER_MAX_LEN_JUMBO), and we have hardware in production now that >>> defaults to 12000. The ixgbe driver doesn't use this constant, bu >>> the cxgbe driver does. Does anyone know a reason I should *not* >>> increase it to a more reasonable level? (9216 would be my choice if >>> we wanted to stick with values in the 9k range.) > > Per above, the various drivers should just be fixed to not use this > define... > > P.S. So, apparently people do use jumbo frames. My question to people > using them is do you limit your use of jumbo frames to broadcast domains > where you can set the MTU properly on all the machine in the domain? Do > you have to do special work to make sure you get the correct MTU to be > compatible w/ all your hardware? i.e. find the hardware w/ the smallest > supported MTU and use that? > > Please reply in private mail unless you feel that your response would > be useful for the whole list. I have a project that I'd like to do that > would allow easier and wide spread use of jumbo frames. > > Thanks. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52CCAA85.60107>