Date: Mon, 19 Aug 2013 23:08:07 +0200 From: Andre Oppermann <andre@freebsd.org> To: Peter Grehan <grehan@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Navdeep Parhar <np@FreeBSD.org> Subject: Re: svn commit: r254520 - in head/sys: kern sys Message-ID: <52128937.1010407@freebsd.org> In-Reply-To: <5212587A.2080202@freebsd.org> References: <201308191116.r7JBGsc6065793@svn.freebsd.org> <521256CE.6070706@FreeBSD.org> <5212587A.2080202@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Mbuf is a core system for the kernel and we should avoid to kitchen-sink it again while at the same time to keep speedy enough to keep up with the speed requirements. I believe it would be bad to have Navdeep, you and others invent their own network buffer management routines over again in slightly different ways tailored to each immediate use case. Can you please describe your intended use of M_NOFREE to better understand the shortcomings of the current mbuf systems and the additional advantages of the M_NOFREE case? -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52128937.1010407>