BCE on FreeBSD and oversized packet acceptance.

Julian Elischer julian at elischer.org
Sat Sep 15 10:41:01 PDT 2007


Mike Karels wrote:
>> I'd like to just ask around as to whether relaxing the limit on drivers
>> makes sense, and if so, how much to relax it.  While we're about it,
>> what size is the actual maximal sized jumbo packet we will ever see? (including
>> likely misconfigurations).
> 
>> It is possible we should just allow any packet that fits into the allocated memory,
>> though one might suggest we just allow say 32 bytes of leeway or something.
> 
> My personal opinion is that drivers should accept anything that is
> convenient to accept, at least up to the size that standards would
> dictate.  The HP situation is unfortunate, but I don't see any good
> reason to reject those frames.  If the above means up to MCLBYTES (2K),
> that doesn't bother me.


Normal packet storage is MCLBYTES (2k) so I think that under normal 
situations we should receive any packet up to that (plus or minus 
any mailbox info that a driver also wants to put in there 
(e.g. the bce driver)). Generally when the MTU is greater than some 
number the driver will allocate jumbo buffers. I'm not quite sure 
what exact size that is but I see we do 9K and 16k variants.
Some documents I've seen mention 9216 (9 x 1024) and others talk 
about 9000. I've also seen 9100, 9160 and 9200 mentioned and one mention I think of 9220
which seems a bit of an odd man out.


> 
> Jumbo is another story.  The maximum size is hardware-dependent.  It
> seeems that most NICs will handle an MTU of 9000, but the actual limit
> varies a lot.  If I recall correctly, some em cards will do about 16K,
> but newer cards have a lower limit.

there seems to be a lot of confusion about this limit.

> 
> Secure Computing (my employer) has a modification that seems reasonable
> to me (well, I guess I wouldn't have done it otherwise).  We adopted the
> existing but unused JUMBO_MTU capability flag, and, if enabled, instructs
> the driver to receive jumbo frames according to the hardware limits.  With
> that flag, the MTU may be 1500, but the driver is still instructed to
> receive jumbo frames even without sending them.  The reason for this
> is the lack of a way to negotiate the use of jumbo frames per host
> (as far as I know; such a thing would certainly be useful, though).

certainly the adoption of that flag is reasonable.
is it settable from ifconfig?
it's probably better than saying "enable jumbo reception 
if mtu is greater than 1600 bytes" or whatever.. 

> 
> Mostly, I'd still go with "be conservative in what you send, liberal
> in what you accept."
> 
> 		Mike



More information about the freebsd-net mailing list