From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 0C0E15A86 for ; Fri, 27 Mar 2015 15:07:47 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YbUv9-0006FH-Ve; Fri, 27 Mar 2015 10:07:45 -0400 Date: Fri, 27 Mar 2015 10:07:35 -0400 From: Neil Horman To: Bruce Richardson Message-ID: <20150327140735.GG5375@hmsreliant.think-freely.org> References: <1427404494-27256-1-git-send-email-bruce.richardson@intel.com> <20150327102956.GB5375@hmsreliant.think-freely.org> <20150327113238.GA11660@bricha3-MOBL3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150327113238.GA11660@bricha3-MOBL3> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] mbuf: add comment explaining confusing code X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 14:07:47 -0000 On Fri, Mar 27, 2015 at 11:32:38AM +0000, Bruce Richardson wrote: > On Fri, Mar 27, 2015 at 06:29:56AM -0400, Neil Horman wrote: > > On Thu, Mar 26, 2015 at 09:14:54PM +0000, Bruce Richardson wrote: > > > The logic used in the condition check before freeing an mbuf is > > > sometimes confusing, so explain it in a proper comment. > > > > > > Signed-off-by: Bruce Richardson > > > --- > > > lib/librte_mbuf/rte_mbuf.h | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > > > index 17ba791..0265172 100644 > > > --- a/lib/librte_mbuf/rte_mbuf.h > > > +++ b/lib/librte_mbuf/rte_mbuf.h > > > @@ -764,6 +764,16 @@ __rte_pktmbuf_prefree_seg(struct rte_mbuf *m) > > > { > > > __rte_mbuf_sanity_check(m, 0); > > > > > > + /* > > > + * Check to see if this is the last reference to the mbuf. > > > + * Note: the double check here is deliberate. If the ref_cnt is "atomic" > > > + * the call to "refcnt_update" is a very expensive operation, so we > > > + * don't want to call it in the case where we know we are the holder > > > + * of the last reference to this mbuf i.e. ref_cnt == 1. > > > + * If however, ref_cnt != 1, it's still possible that we may still be > > > + * the final decrementer of the count, so we need to check that > > > + * result also, to make sure the mbuf is freed properly. > > > + */ > > > if (likely (rte_mbuf_refcnt_read(m) == 1) || > > > likely (rte_mbuf_refcnt_update(m, -1) == 0)) { > > > > > > -- > > > 2.1.0 > > > > > > > > > > NAK > > the comment is incorrect, a return code of 1 from rte_mbuf_refcnt_read doesn't > > guarantee you are the last holder of the buffer if two contexts have a pointer > > to it. > If two threads have pointers to it, and are both going to free it, the refcnt > must be 2 not one, otherwise the refcnt is meaningless. > What about the other concrete case that I illustrated, where one context is attempting to increment the refcount, while the other is decrementing it with the intention to free? By making the read and set operation disctinct here you've broken the atomicity of the read and update logic that atomics are there for and created a race condition. I don't know how else to explain this to you. if(atomic_read == 1) then atomic_set(0), breaks the entire notion of what atomics are meant to do (namely update and read state as an atomic unit), you just can't get away with not having that atomicity here. If you could, you might as well be using plain integers for the reference count, as you're not using the atomic properties of the type. Neil > /Bruce > > > > > Zoltans patch is the correct solution here, expensive or not. I wrote up my > > explination in this thread: > > http://dpdk.org/ml/archives/dev/2015-March/015839.html > > > > >