Date: Wed, 21 Aug 2013 17:02:59 +0200 From: Andre Oppermann <andre@freebsd.org> To: Navdeep Parhar <np@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Peter Grehan <grehan@freebsd.org> Subject: Re: svn commit: r254520 - in head/sys: kern sys Message-ID: <5214D6A3.608@freebsd.org> In-Reply-To: <52129634.7000509@FreeBSD.org> References: <201308191116.r7JBGsc6065793@svn.freebsd.org> <521256CE.6070706@FreeBSD.org> <5212587A.2080202@freebsd.org> <52128937.1010407@freebsd.org> <52129634.7000509@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20.08.2013 00:03, Navdeep Parhar wrote: > On 08/19/13 14:08, Andre Oppermann wrote: >> On 19.08.2013 19:40, Peter Grehan wrote: >>>> I recently tried some experiments to reduce the number of mbuf and >>>> cluster allocations in a 40G NIC driver. M_NOFREE and EXT_EXTREF proved >>>> very useful and the code changes to the kernel were minimal. See >>>> user/np/cxl_tuning. The experiment was quite successful and I was >>>> planning to bring in most of those changes to HEAD. I was hoping to get >>>> some runtime mileage on the approach in general before tweaking the >>>> ctors/dtors for jumpbo, jumbo9, jumbo16 to allow for an mbuf+refcnt >>>> within the cluster. But now M_NOFREE has vanished without a warning... >>> >>> I also had a virtualization work-in-progress where static mbufs were >>> allocated in the kernel and >>> M_NOFREE set. >>> >>> Might be worth sending a prior heads-up for these type of changes. >> >> I'm sorry for ambushing but this stuff has to be done. I have provided >> an alternative way of handling it and I'm happy to help you with your >> use case to make it good for you and to prevent the mbuf system from >> getting bloated and hackish again. > > I don't know what Peter's use case is but I'm curious about the > already-available alternative to M_NOFREE, if that's what you meant. > Can you please elaborate? When you supply your own (*ext_free) function you can simply omit freeing the mbuf itself. Should make sure not to leak it though. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5214D6A3.608>