From owner-freebsd-net@FreeBSD.ORG Wed Jan 8 03:40:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80C922A6 for ; Wed, 8 Jan 2014 03:40:14 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56E571514 for ; Wed, 8 Jan 2014 03:40:14 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s083e0v3023323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 19:40:01 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s083e0CV023307; Tue, 7 Jan 2014 19:40:00 -0800 (PST) (envelope-from jmg) Date: Tue, 7 Jan 2014 19:40:00 -0800 From: John-Mark Gurney To: Joe Holden Subject: Re: ETHER_MAX_LEN_JUMBO Message-ID: <20140108033959.GX99167@funkthat.com> Mail-Followup-To: Joe Holden , Garrett Wollman , freebsd-net@freebsd.org References: <21196.29430.733181.353677@hergotha.csail.mit.edu> <52CC9EF0.5010504@rewt.org.uk> <20140108012215.GV99167@funkthat.com> <52CCAA85.60107@rewt.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52CCAA85.60107@rewt.org.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 07 Jan 2014 19:40:01 -0800 (PST) Cc: freebsd-net@freebsd.org, Garrett Wollman X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 03:40:14 -0000 Joe Holden wrote this message on Wed, Jan 08, 2014 at 01:31 +0000: > 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. I used fxr.watson.org to do this research: http://fxr.watson.org/fxr/ident?i=ETHER_MAX_LEN_JUMBO Just so you can browse around for yourself. :) Hmm.. to make matters more interesting, the kernel version of cxgb does not default to jumbo frames, BUT, the module version of cxgb does default.. It's probably because no one uses the module that no one noticed the difference... If you need help generating patches, let me know.. I can commit them once they are tested, but I don't have hardware to test myself... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."