Date: Wed, 21 Aug 2013 09:38:49 -0700 From: Navdeep Parhar <np@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org> Cc: svn-src-head@freebsd.org, freebsd-net@freebsd.org, Peter Grehan <grehan@freebsd.org> Subject: Re: M_NOFREE removal (was Re: svn commit: r254520 - in head/sys: kern sys) Message-ID: <5214ED19.40907@FreeBSD.org> In-Reply-To: <5214D7E8.1080106@freebsd.org> References: <201308191116.r7JBGsc6065793@svn.freebsd.org> <521256CE.6070706@FreeBSD.org> <5212587A.2080202@freebsd.org> <52128937.1010407@freebsd.org> <52129E55.30803@freebsd.org> <5214D7E8.1080106@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/21/13 08:08, Andre Oppermann wrote: > On 20.08.2013 00:38, Peter Grehan wrote: <snip> > >> If there's an alternative to M_NOFREE, I'd be more than happy to use >> that. > > Set up your own (*ext_free) function and omit freeing of the mbuf > itself. Make > sure to properly track your mbufs to avoid leaking them. > How is this an alternate to M_NOFREE? Your suggestion indicates that you may have removed M_NOFREE thinking it did something other than what it actually did. And this suggestion doesn't even work -- note the uma_zfree(zone_mbuf, m) at the end of mb_free_ext that would run after any custom ext_free. To recap: M_NOFREE was the way to tell the mbuf subsystem that the mbuf does not come from zone_mbuf. Nothing more and nothing less. The mbuf was in other ways like any other mbuf and could have a pkthdr (or not), internal storage (or not), external cluster (or not), etc. etc. Regards, Navdeep
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5214ED19.40907>