From owner-freebsd-net@FreeBSD.ORG Wed Aug 21 18:18:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D165AD73 for ; Wed, 21 Aug 2013 18:18:44 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED3692F38 for ; Wed, 21 Aug 2013 18:18:43 +0000 (UTC) Received: (qmail 73503 invoked from network); 21 Aug 2013 19:01:46 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Aug 2013 19:01:46 -0000 Message-ID: <5215047C.8080107@freebsd.org> Date: Wed, 21 Aug 2013 20:18:36 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Navdeep Parhar Subject: Re: M_NOFREE removal (was Re: svn commit: r254520 - in head/sys: kern sys) 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> <5214ED19.40907@FreeBSD.org> In-Reply-To: <5214ED19.40907@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, freebsd-net@freebsd.org, Peter Grehan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 18:18:44 -0000 On 21.08.2013 18:38, Navdeep Parhar wrote: > On 08/21/13 08:08, Andre Oppermann wrote: >> On 20.08.2013 00:38, Peter Grehan wrote: > >> >>> 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. Mea culpa. You're totally right. I have mixed up my mental model with another working tree I carry along for quite some time. In it (*ext_free) completely replaces mb_free_ext() making it very easy to keep the mbuf. We should move that way hopefully sooner than later, simplifying a couple of things including externally managed refcounts. Sorry for the chaos and not getting it. M_NOFREE is back with r254605. -- Andre