From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <3chas3@gmail.com>
Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com
 [209.85.216.176]) by dpdk.org (Postfix) with ESMTP id 9BC51968
 for <dev@dpdk.org>; Wed,  6 Sep 2017 15:55:33 +0200 (CEST)
Received: by mail-qt0-f176.google.com with SMTP id m35so19876979qte.1
 for <dev@dpdk.org>; Wed, 06 Sep 2017 06:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=message-id:subject:from:to:cc:date:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=jsH8zcx/JTvmGHeHDwcEP2bMbbLtNh0S7RKbZ2PCjLM=;
 b=Pt23mNgNxeqkJX4cWaE0kDSfbyrNjNauJKwxj7y8nAjfcpRAn3DwlY8+rW6uMDgoN/
 qHljYJfHTUwmMf7HsRwo4BlF/YcjeBQlVLA3NYRZSEWOVd+rKlwc2nUzVIhY1+kSCJaU
 6t+gQwTCkSc8VirNAtGnz6fezgY5BjDf/CoV+xJrrOYCpf3VsQ+PR/A0A6OArw5u5tKA
 upkn+RyGceFKSnM9FoyituNmzLDG4S+o5O7CLw0FWC5mpKae6+ZTyj1tMNttuQNY2YO4
 Vq/3bxshOq/nvP0os+Hvs6hPUu8Jr2ZaJSZw0YOseMt/huK57bIo38KdXInppIjCiu4v
 bzmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=jsH8zcx/JTvmGHeHDwcEP2bMbbLtNh0S7RKbZ2PCjLM=;
 b=JeyTzR1LSCdZ4uaXcLpuPsk9yjDcLdI067uUmalwwMbmEaW4gyRk3bW/SbugTJ3m23
 OziC7va4zuOJgjYswBR95aUIoUg6GTKNRMuLMwc3h6vCajpAhxKnBUaPD/h2OKuh3QSS
 x/vzm70ZUpsg+At6VukBr2Vs8JDuW8Z0D9Dm5fQQsL7f5MwAs24PXgDJBPJAHtlMjrqM
 bU78ny4PBXCYXfvp4i4I8FbbQj9z3V1UitVGtp0eVazNmuyldNl67u3ekE844VREU1b9
 oRH/3wxBOTSw1lJhhvp3DvPOTqARq0/jHvqN2M9au8qwwADA3AjAwJCu/OHAU0cPyUw6
 oanw==
X-Gm-Message-State: AHPjjUhesUHeU1uEHAtPcrQJyQaL7xQ865jkbxlA8NQRCLHIn5hfHXFP
 Xe+GAeqTrXzI3A==
X-Google-Smtp-Source: AOwi7QBrER11OkKUHHGFXh3kYvc3uwlFK/77NPYUULf+WJrvyW4+izXvRGuH/rejMqc8qqA/KAgVBQ==
X-Received: by 10.200.3.14 with SMTP id q14mr3320804qtg.336.1504706132733;
 Wed, 06 Sep 2017 06:55:32 -0700 (PDT)
Received: from monolith.home (pool-96-255-82-208.washdc.fios.verizon.net.
 [96.255.82.208])
 by smtp.googlemail.com with ESMTPSA id f48sm2275553qtc.49.2017.09.06.06.55.31
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Wed, 06 Sep 2017 06:55:31 -0700 (PDT)
Message-ID: <1504706130.2192.11.camel@gmail.com>
From: Chas Williams <3chas3@gmail.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "Nicolau, Radu"
 <radu.nicolau@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "olivier.matz@6wind.com" <olivier.matz@6wind.com>, "cw817q@att.com"
 <cw817q@att.com>
Date: Wed, 06 Sep 2017 09:55:30 -0400
In-Reply-To: <2601191342CEEE43887BDE71AB9772584F248208@irsmsx105.ger.corp.intel.com>
References: <1502120243-8902-1-git-send-email-ciwillia@brocade.com>
 <1502122274-15657-1-git-send-email-ciwillia@brocade.com>
 <bff4a6bc-4a57-e9c4-4208-d5950f2f122b@intel.com>
 <1504694773.2192.9.camel@gmail.com>
 <2601191342CEEE43887BDE71AB9772584F248208@irsmsx105.ger.corp.intel.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v2] mbuf: use refcnt = 0 when debugging
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Sep 2017 13:55:34 -0000

On Wed, 2017-09-06 at 11:58 +0000, Ananyev, Konstantin wrote:
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Chas Williams
> > Sent: Wednesday, September 6, 2017 11:46 AM
> > To: Nicolau, Radu <radu.nicolau@intel.com>; dev@dpdk.org
> > Cc: olivier.matz@6wind.com; cw817q@att.com
> > Subject: Re: [dpdk-dev] [PATCH v2] mbuf: use refcnt = 0 when debugging
> > 
> > [Note: My former email address is going away eventually.  I am moving the
> > conversation to my other email address which is a bit more permanent.]
> > 
> > On Mon, 2017-09-04 at 15:27 +0100, Radu Nicolau wrote:
> > >
> > > On 8/7/2017 5:11 PM, Charles (Chas) Williams wrote:
> > > > After commit 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool") is it
> > > > much harder to detect a "double free".  If the developer makes a copy
> > > > of an mbuf pointer and frees it twice, this condition is never detected
> > > > and the mbuf gets returned to the pool twice.
> > > >
> > > > Since this requires extra work to track, make this behavior conditional
> > > > on CONFIG_RTE_LIBRTE_MBUF_DEBUG.
> > > >
> > > > Signed-off-by: Chas Williams <ciwillia@brocade.com>
> > > > ---
> > > >
> > > > @@ -1304,10 +1329,13 @@ rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> > > >   			m->next = NULL;
> > > >   			m->nb_segs = 1;
> > > >   		}
> > > > +#ifdef RTE_LIBRTE_MBUF_DEBUG
> > > > +		rte_mbuf_refcnt_set(m, RTE_MBUF_UNUSED_CNT);
> > > > +#endif
> > > >
> > > >   		return m;
> > > >
> > > > -       } else if (rte_atomic16_add_return(&m->refcnt_atomic, -1) == 0) {
> > > > +	} else if (rte_mbuf_refcnt_update(m, -1) == 0) {
> > > Why replace the use of atomic operation?
> > 
> > It doesn't.  rte_mbuf_refcnt_update() is also atomic(ish) but it slightly more
> > optimal.  This whole section is a little hazy actually.  It looks like
> > rte_pktmbuf_prefree_seg() unwraps rte_mbuf_refcnt_update() so they can avoid
> > setting the refcnt when the refcnt is already the 'correct' value.
> 
> You don't need to use refcnt_update() here - if you take that path it already means
> that m->refcnt_atomic != 1.
> In fact, I think using refcnt_update () here might be a bit slower - as it means extra read.
> Konstantin

Yes, that is somewhat the point.  If a mbuf can have a refcnt of 0,
then we want to go into rte_mbuf_refcnt_update() which detects 0 -> -1.
I could explicitly check this in prefree_seg but I was just restored the
previous call into refcnt_update.  I could explicitly check for refcnt =
0 in prefree_seg() but since we do have a routine for this...

> > > >
> > > >
> > > >   		if (RTE_MBUF_INDIRECT(m))
> > > > @@ -1317,7 +1345,7 @@ rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> > > >   			m->next = NULL;
> > > >   			m->nb_segs = 1;
> > > >   		}
> > > > -		rte_mbuf_refcnt_set(m, 1);
> > > > +		rte_mbuf_refcnt_set(m, RTE_MBUF_UNUSED_CNT);
> > > >
> > > >   		return m;
> > > >   	}
> > > Reviewed-by:  Radu Nicolau <radu.nicolau@intel.com>
> > 
> > Thanks for the review.