From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 15:26:37 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 95EE916A417 for ; Sat, 15 Sep 2007 15:26:37 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5215D13C4B6 for ; Sat, 15 Sep 2007 15:26:37 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l8FEqHwV041276; Sat, 15 Sep 2007 09:52:19 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200709151452.l8FEqHwV041276@redrock.karels.net> To: Julian Elischer From: Mike Karels In-reply-to: Your message of Fri, 14 Sep 2007 12:57:01 -0700. <46EAE78D.8060108@elischer.org> Date: Sat, 15 Sep 2007 09:52:17 -0500 Sender: karels@karels.net 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 Reply-To: karels@karels.net 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 15:26:37 -0000 > 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. 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. 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). Mostly, I'd still go with "be conservative in what you send, liberal in what you accept." Mike