From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 17:41:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCACB16A418 for ; Sat, 15 Sep 2007 17:41:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA8A13C468 for ; Sat, 15 Sep 2007 17:41:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sat, 15 Sep 2007 10:40:58 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id ADF3E1263C8; Sat, 15 Sep 2007 10:40:57 -0700 (PDT) Message-ID: <46EC1929.5020706@elischer.org> Date: Sat, 15 Sep 2007 10:40:57 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: karels@karels.net References: <200709151452.l8FEqHwV041276@redrock.karels.net> In-Reply-To: <200709151452.l8FEqHwV041276@redrock.karels.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , David Christensen , Jack Vogel Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 17:41:01 -0000 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