From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3765DA053D; Fri, 17 Jul 2020 18:20:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 737142C57; Fri, 17 Jul 2020 18:20:21 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id D05862C38 for ; Fri, 17 Jul 2020 18:20:19 +0200 (CEST) IronPort-SDR: Qp/n1ISh7GbmeLIE0Vx5v18jnSOabczFGS939kvvK528uLBbOxkWb7j5XgltT7TSmafGh1MmlK 8Z/gvVR+V/LA== X-IronPort-AV: E=McAfee;i="6000,8403,9685"; a="137089328" X-IronPort-AV: E=Sophos;i="5.75,362,1589266800"; d="scan'208";a="137089328" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2020 09:20:18 -0700 IronPort-SDR: u1tlUclHbM02YtUt1m+tlArfjaT3eOZGlVsUZqaErdaxwrXxJYywNIaI03aPamzoBc3AnYmLm1 KLOyItZb8nug== X-IronPort-AV: E=Sophos;i="5.75,362,1589266800"; d="scan'208";a="460895471" Received: from bricha3-mobl.ger.corp.intel.com ([10.213.193.115]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 17 Jul 2020 09:20:15 -0700 Date: Fri, 17 Jul 2020 17:20:12 +0100 From: Bruce Richardson To: David Marchand Cc: "Ananyev, Konstantin" , dev , Olivier Matz , Stephen Hemminger , David Christensen , Honnappa Nagarahalli , "Ruifeng Wang (Arm Technology China)" , nd , Ray Kinsella , Neil Horman , John McNamara , Marko Kovacevic , Phil Yang Message-ID: <20200717162012.GB719@bricha3-MOBL.ger.corp.intel.com> References: <1594310331-23345-1-git-send-email-phil.yang@arm.com> <1594960611-19470-1-git-send-email-phil.yang@arm.com> <1594960611-19470-2-git-send-email-phil.yang@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v5 2/2] doc: announce deprecation of refcnt atomic member X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jul 17, 2020 at 04:35:56PM +0200, David Marchand wrote: > On Fri, Jul 17, 2020 at 4:32 PM David Marchand > wrote: > > > > On Fri, Jul 17, 2020 at 6:37 AM Phil Yang wrote: > > > > > > refcnt_atomic member in structures rte_mbuf and rte_mbuf_ext_shared_info > > > will be deprecated in 20.11 release. > > > > > > Suggested-by: Honnappa Nagarahalli > > > Signed-off-by: Phil Yang > > > Acked-by: Konstantin Ananyev > > > --- > > > doc/guides/rel_notes/deprecation.rst | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > > > index a58a179..99c9806 100644 > > > --- a/doc/guides/rel_notes/deprecation.rst > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > @@ -129,6 +129,12 @@ Deprecation Notices > > > in "rte_sched.h". These changes are aligned to improvements suggested in the > > > RFC https://mails.dpdk.org/archives/dev/2018-November/120035.html. > > > > > > +* mbuf: ``refcnt_atomic`` member in structures ``rte_mbuf`` and > > > + ``rte_mbuf_ext_shared_info`` is of type ``rte_atomic16_t``. Due to adoption > > > + of C11 atomic builtins it will be of type ``uint16_t``. ``refcnt_atomic`` > > > + will be removed in 20.11. It will be replaced with ``refcnt`` of type > > > + ``uint16_t``. > > > + > > > * metrics: The function ``rte_metrics_init`` will have a non-void return > > > in order to notify errors instead of calling ``rte_exit``. > > > > > > -- > > > 2.7.4 > > > > > > > Acked-by: David Marchand > > Bruce, Konstantin, > > This precedes the first open source release so trying with you guys: > what is the purpose of the RTE_MBUF_REFCNT_ATOMIC build flag? > Thanks. > That's indeed going back a long way! IIRC When we first introduced a reference count, I believe we considered cases where we would not need atomics to work on the ref count, and added the build macro to remove the cost of the atomic in those instances. For example, if a TCP stack wanted to hold on to an mbuf after transmission rather than having it freed to the mempool (in case it needed to be retransmitted), it could increment the reference count to ensure that did not occur. Later if an ack for the TCP packet was received the buffer could be freed. So long as the same thread that did the TX freed the buffer later, no atomic increment or decrement was necessary. Similarly for a run-to-completion app which fragmented packets using multiple mbufs referencing a single packet buffer. So long as only a single thread worked on the buffer, the reference counters need not be atomic. In practice, the general case needs to be atomic ref-counts, and I'm not sure who, if anyone, uses this setting in their apps. It should be convertable to a runtime setting if needed. /Bruce