Date: Tue, 12 Mar 2013 19:50:05 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r248196 - head/sys/nfs Message-ID: <20130312155005.GJ48089@FreeBSD.org> In-Reply-To: <513F4A39.8040107@freebsd.org> References: <201303121219.r2CCJN5Z069789@svn.freebsd.org> <513F3A54.3090702@freebsd.org> <20130312150053.GI48089@FreeBSD.org> <513F4A39.8040107@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130312155005.GJ48089>