From owner-svn-src-head@FreeBSD.ORG Fri Feb 1 21:57:16 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D0AEA8C0 for ; Fri, 1 Feb 2013 21:57:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2D67AE6 for ; Fri, 1 Feb 2013 21:57:15 +0000 (UTC) Received: (qmail 46866 invoked from network); 1 Feb 2013 23:16:50 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Feb 2013 23:16:50 -0000 Message-ID: <510C3A34.3040702@freebsd.org> Date: Fri, 01 Feb 2013 22:57:08 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Juli Mallett Subject: Re: svn commit: r246204 - head/sys/arm/include References: <201302011026.r11AQVL9068427@svn.freebsd.org> <510C00CB.8000409@rice.edu> <510C1E7A.2090509@freebsd.org> <510C2D24.60303@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, Adrian Chadd , src-committers@freebsd.org, svn-src-all@freebsd.org, Alan Cox X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 21:57:16 -0000 On 01.02.2013 22:16, Juli Mallett wrote: > On Fri, Feb 1, 2013 at 1:01 PM, Andre Oppermann wrote: >> On 01.02.2013 21:23, Adrian Chadd wrote: >>> >>> .. before you make that assumption, please re-visit some the .. >>> lower-end integrated ethernet MACs in embedded chips. >>> >>> I don't know whether the Atheros stuff does (I think it does, but I >>> don't know under what conditions it's possible.) >>> >>> Maybe have it by default not return jumbo mbufs, and if a driver wants >>> jumbo mbufs it can explicitly ask for them. >> >> >> Jumbo frames do not see wide-spread use. If they are used, then >> in data centre LAN environments and possibly also inter-datacenter. >> That is high performance environments. >> >> I seriously doubt that lower-end ethernet MACs you're referring to >> fit that bill. > > These are silly generalizations, Andre. I know of low-end systems in > jumbo frame environments. I think Adrian's implication that Atheros > hardware can't handle doing scatter-gather into multiple buffers for > jumbo frames is probably an unlikely one, but if we have hardware that > requires jumbo mbufs, we should obviously keep supporting jumbo mbufs > to some extent. My generalizations are about as silly as Adrian's handwaving. ;) The reason jumbo mbufs (> PAGE_SIZE) ever came into existence was for non-s/g DMA network cards, the Tigeon(II) in particular IIRC. Jumbo mbufs are much more taxing on the on VM and the kernel_map because of the contigmalloc requirement. They should only be used when really necessary in the receive path and not as general purpose extra large mbufs. That's what we've got mbuf chains for. The send path from userspace uses PAGE_SIZE (jumbo) mbuf's whenever possible. The same is true for sendfile() because it wraps file object pages to mbufs. > Hypotheticals are somewhat irrelevant, but I find it surprising that > you're being so glib about breaking FreeBSD networking just because of > an idea you have about where jumbo frame use is appropriate and what > kinds of hardware should be connected to jumbo frame networks. First I said I'd love to remove it. Not that I'm doing now or soon. It's an opinion and expression of desire. Second very little would break because any contemporary network card (I have looked at so far) supports jumbo frame s/g into 2K or 4K mbufs on receive. Jumbo frames are only available with GigE and 10GigE. It was never supported on 100M. Any patch removing large jumbo support wouldn't go unnoticed. ;) -- Andre