From owner-svn-src-head@FreeBSD.ORG Tue Mar 12 15:50:07 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 164D1D11; Tue, 12 Mar 2013 15:50:07 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7F24D739; Tue, 12 Mar 2013 15:50:05 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r2CFo53C097176; Tue, 12 Mar 2013 19:50:05 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r2CFo5ix097175; Tue, 12 Mar 2013 19:50:05 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 12 Mar 2013 19:50:05 +0400 From: Gleb Smirnoff To: Andre Oppermann Subject: Re: svn commit: r248196 - head/sys/nfs Message-ID: <20130312155005.GJ48089@FreeBSD.org> References: <201303121219.r2CCJN5Z069789@svn.freebsd.org> <513F3A54.3090702@freebsd.org> <20130312150053.GI48089@FreeBSD.org> <513F4A39.8040107@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <513F4A39.8040107@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org 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: Tue, 12 Mar 2013 15:50:07 -0000 On Tue, Mar 12, 2013 at 04:31:05PM +0100, Andre Oppermann wrote: A> > If you are concerned about using jumbos that are > PAGE_SIZE, then I can A> > extend API in my patch. ... done. A> > A> > Patch attached. A> > A> > The NFS code itself guarantees that it won't request > than MCLBYTES, A> > so using bare m_get2() here is safe. I can add flag there later for A> > clarity. A> A> Using PAGE_SIZE clusters is perfectly fine and no flag to prevent that A> is necessary. In fact we're doing it for years on socket writes without A> complaints (through m_getm2()). mbuf usage isn't limited to sockets. There is some code that right now utilizes only mbufs and standard clusters, netipsec for example. I'd like to remove a lot of handmade mbuf allocating, in different places in kernel and this can be done with M_NOJUMBO flag. I don't have time to dig more deep into large chunks of code trying to understand whether it is possible to convert them into using PAGE_SIZE clusters or not, I just want to reduce amount of pasted hand allocating. We have very common case when we allocate either mbuf or mbuf + cluster, depending on size. Everywhere this is made by hand, but can be substituted with m_get2(len, ..., M_NOJUMBO); A> However I think that m_get2() should never ever even try to attempt to A> allocate mbuf clusters larger than PAGE_SIZE. Not even with flags. A> A> All mbufs > PAGE_SIZE should be exclusively and only ever be used by drivers A> for NIC's with "challenged" DMA engines. Possibly only available through a A> dedicated API to prevent all other uses of it. Have you done any benchmarking that proves that scatter-gather on the level of busdma is any worse than chaining on mbuf level? Dealing with contiguous in virtual memory mbuf is handy, for protocols that look through entire payload, for example pfsync. I guess NFS may also benefit from that. P.S. Ok about the patch? -- Totus tuus, Glebius.