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 F1E16A0526; Wed, 8 Jul 2020 13:43:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CC7FE1DAEB; Wed, 8 Jul 2020 13:43:04 +0200 (CEST) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by dpdk.org (Postfix) with ESMTP id 502C81DABF for ; Wed, 8 Jul 2020 13:43:03 +0200 (CEST) Received: by mail-wm1-f68.google.com with SMTP id l17so2641955wmj.0 for ; Wed, 08 Jul 2020 04:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=svx83nvZERQFqUQfmEPl2hP1X81LdN3kgCUVXHG/V1I=; b=S2U7tqHNgA8KchmmtKbhknJjst5PU5HcZM2bNj1wzfbr3/OX96VlGRiwP49UYZqeNp ISb99sDpCN4I6SHM8xRMwEKIoH1dJryeHSWIPLF8EivSjIs1smAdCubBnaZY5OTJMb6l FKlZKMgOUHTM3+ySc9MPCC+Nb5er5gHNhkt19sN1l1CZE66uinlm8b3rvYAd81JzF6UJ p6E+7lvKWa57aUPNQgBagCen0mWcuPgLUUt1VNwOK2Bx6hNh9f5crlbJHWmcCQCf/BoZ 2gxN7BlMdRaNurxiiI1ikuBT7HUe5Rm2oJSJUM7xAhHdA9RHh3rzwkkNJleu/iyMD8B8 q/Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=svx83nvZERQFqUQfmEPl2hP1X81LdN3kgCUVXHG/V1I=; b=C68pAZ3n1sUqpBKrznOi52kQAVuSyvxR+Pg8yOtlErJZPDDvjFdNYGsJb+5u3lsFsM UqY2HwGd61iNCtfHwFD6qoGCuhNfSRUdM4PuRdnYl1EKSopVFNoQW2705CA8aWlCu34k KK6REXkzJ4Jum8d/sw0THI2wJafvSDX+IEk2FT8uAWeCZ4fUgN0UmtHr9nR/EI/lkAYi SUvp8gw24fFeQR2J60eY9YMar2w2phtD3TOQoEVfUPowA3mDuH1FdcxD9ugrTo6j7I5k DqaBxaJ6mwgfJpiYf6D+bPNnumZf3tvEzXkA8LMO95o63/DuwJScmQDyaCmbq9jp3K7E K3oQ== X-Gm-Message-State: AOAM533iAs5fozENLZXDlhzLgJ3y7JXwbffWey5kLfOwiZULSWlf1Q0o xQTp4k4JJ7YmL109Q+oR4uUhGg== X-Google-Smtp-Source: ABdhPJxot5u98FlIahMhSBDFJK4ea6mT7mtnZInp2Xr5kdNLGS5hiC9n2wu/z1F7y9hEKLewlLcluw== X-Received: by 2002:a7b:c0c9:: with SMTP id s9mr8423135wmh.166.1594208583121; Wed, 08 Jul 2020 04:43:03 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id g3sm6384620wrb.59.2020.07.08.04.43.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2020 04:43:02 -0700 (PDT) Date: Wed, 8 Jul 2020 13:43:02 +0200 From: Olivier Matz To: Phil Yang Cc: Stephen Hemminger , "david.marchand@redhat.com" , "dev@dpdk.org" , "drc@linux.vnet.ibm.com" , Honnappa Nagarahalli , Ruifeng Wang , nd Message-ID: <20200708114301.GN5869@platinum> References: <1591871178-12542-1-git-send-email-phil.yang@arm.com> <1594116633-14554-1-git-send-email-phil.yang@arm.com> <20200707101314.42df824c@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v2] mbuf: use C11 atomics for refcnt operations 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 Wed, Jul 08, 2020 at 04:48:33AM +0000, Phil Yang wrote: > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Wednesday, July 8, 2020 1:13 AM > > To: Phil Yang > > Cc: david.marchand@redhat.com; dev@dpdk.org; drc@linux.vnet.ibm.com; > > Honnappa Nagarahalli ; > > olivier.matz@6wind.com; Ruifeng Wang ; nd > > > > Subject: Re: [dpdk-dev] [PATCH v2] mbuf: use C11 atomics for refcnt > > operations > > > > On Tue, 7 Jul 2020 18:10:33 +0800 > > Phil Yang wrote: > > > > > + return (uint16_t)(__atomic_add_fetch((int16_t *)&shinfo- > > >refcnt_atomic, > > > + > > > > Why do you need so many casts here? > > The type of refcnt_atomic is now uint16 after your patch. > > In the existing code, the input parameter type for this API is signed integer. For example: > drivers/net/netvsc/hn_rxtx.c:531 > lib/librte_mbuf/rte_mbuf.h:1194 > > However, the output type of rte_mbuf_ext_refcnt related APIs is not uniform. We use these typecast to consistent with the current API definition. Would it make sense to cast the increment instead? I mean: return __atomic_add_fetch(&m->refcnt, (uint16_t)value, __ATOMIC_ACQ_REL); instead of: return (uint16_t)(__atomic_add_fetch((int16_t *)&m->refcnt, value, __ATOMIC_ACQ_REL)); The same could apply to __rte_pktmbuf_pinned_extbuf_decref() I think: > - if (likely(rte_atomic16_add_return > - (&shinfo->refcnt_atomic, -1))) > + if (likely(__atomic_add_fetch((int *)&shinfo->refcnt_atomic, -1, > + __ATOMIC_ACQ_REL))) By the way, why was the cast was to (int *) in this case? I think it can overwrite fields beside refcnt.