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 18B49A0526; Tue, 21 Jul 2020 10:36:20 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3495A1C027; Tue, 21 Jul 2020 10:36:17 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id 38FCC1C025 for ; Tue, 21 Jul 2020 10:36:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595320574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=twvVKw+GNVAzRF60mcIG3/VO7kEzY486moFFEHqNONw=; b=HM6SF0M+sECguCAMrcedB+3DbNJ+Jf/HFBC2M8XNNtTRV/kMBGztWbn3REjT33zw2kxA0+ IUGbcMFQPty4XAPOanGEWcBezdcfiboGDcWQKbdlVeegtGlBfTgbqV5SgLBnIeZQnlquA5 V8sZRgJdYibt8rAOVV0Jc6DsVL35uSc= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-16-iK74y9_MMYalNU2rkvg0eg-1; Tue, 21 Jul 2020 04:36:11 -0400 X-MC-Unique: iK74y9_MMYalNU2rkvg0eg-1 Received: by mail-ua1-f69.google.com with SMTP id 14so3681572uac.8 for ; Tue, 21 Jul 2020 01:36:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=twvVKw+GNVAzRF60mcIG3/VO7kEzY486moFFEHqNONw=; b=MAGPlndsWTq1cNxW6v+2tSd1sk+ZLAI2mqyay1AurreLasAO6VX2w26r7SkvsZBES+ Ynex0Y7+i1kcNFIWtUXP94xm3JBb8Pp7wYIVg1TMWuFSkM+8z6QYveF0VD946iqt661l zuUa/9GI3SegVJ44li+8TQgOWoamNqvSzJFRLGCtWkxEnLsbioCnAfZgbTtVZHEFowZw 0puxhqlSqiKpU1QIfIA7f664m0TOYNcBq3rDStHOFboBAitPqaR58Z5vHbKNsB5ZHQmM NETaMQNEhyu2YbtBfsw9Nc6v+yEhJ+MoVc4Z4u1LSM36BeVpdStpEC+Knp2eIrUiouix w9eg== X-Gm-Message-State: AOAM533ctt6ZhpHH54oORPzCDS/l4NP23MIkilLxrtYnn+X2D/R4xyjL Mc3z+DADlJwOeaG/FJhzSAGzzbivcBy6uWvWPUPMRtomCowcpJNDu/LQiByjnwRlH8QqlTfzD5A weuUvCTqCi3O8A+PxL/E= X-Received: by 2002:a9f:31f3:: with SMTP id w48mr12923295uad.87.1595320571204; Tue, 21 Jul 2020 01:36:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyWPOrc3rjltgNRaUj6sFtji5tGmzuceqs0zgubBI2AsrOqk6dlsY3/NZ2cFB81muuThxJBFjqO7Y3pZLTFrMM= X-Received: by 2002:a9f:31f3:: with SMTP id w48mr12923283uad.87.1595320570934; Tue, 21 Jul 2020 01:36:10 -0700 (PDT) MIME-Version: 1.0 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> <20200717162012.GB719@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20200717162012.GB719@bricha3-MOBL.ger.corp.intel.com> From: David Marchand Date: Tue, 21 Jul 2020 10:35:59 +0200 Message-ID: To: Bruce Richardson , "Ananyev, Konstantin" Cc: 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 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 6:20 PM Bruce Richardson wrote: > > 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. Thanks Bruce and Konstantin. With the switch to meson and not being able to enable/disable this build flag, we will lose this feature. It seems to be a quite special use case, so we might need a new dedicated API? -- David Marchand