Date: Tue, 7 Jan 2014 17:22:15 -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: <20140108012215.GV99167@funkthat.com> In-Reply-To: <52CC9EF0.5010504@rewt.org.uk> References: <21196.29430.733181.353677@hergotha.csail.mit.edu> <52CC9EF0.5010504@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 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...
> 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.
--
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?20140108012215.GV99167>