Date: Mon, 19 Aug 2013 15:03:32 -0700 From: Navdeep Parhar <np@FreeBSD.org> To: Andre Oppermann <andre@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: <52129634.7000509@FreeBSD.org> In-Reply-To: <52128937.1010407@freebsd.org> References: <201308191116.r7JBGsc6065793@svn.freebsd.org> <521256CE.6070706@FreeBSD.org> <5212587A.2080202@freebsd.org> <52128937.1010407@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Regards, Navdeep
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52129634.7000509>