ETHER_MAX_LEN_JUMBO

[Joe Holden]

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.
>