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 3CAD3A0546; Thu, 16 Jul 2020 18:42:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CD3231BED5; Thu, 16 Jul 2020 18:42:46 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id 218AB1BED2 for ; Thu, 16 Jul 2020 18:42:45 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 5CEAF580172; Thu, 16 Jul 2020 12:42:44 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 16 Jul 2020 12:42:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= C54OM6KGmtYCU/P4zMw/3q546D5C1314ynh47KJj3Ss=; b=eP1pXqP2+b85L0Xv JHYFeB9K/k5Oq3Hu0ttykNAibxfylMT+u7W+IuLAHSa4R/TrB74y7Iv1+7kF+xY5 Up6RyoR+2ckylDzSPrOs7zrZMUx5rUWJ+t5reTBesv05RxGIlqZH0/5tMxa66xXn IZ91Eu6lZMHu1BjOifLfmuJRszs2KnVxovKjZr1zBVcu4ykF/46e/WWT6Pre+cJj YclvmggpcF11hBCHGqwD4SlZsWrjE4PxNt8imNo0Ul7QSfrZVGni6NxlJwTfCOMU FwV90BtNNO/GMCoP/GfbJrBzeu7o0MlCipnICY6zy0QnJzxNJA8YqzjKp1rUt2Gm ZngQPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=C54OM6KGmtYCU/P4zMw/3q546D5C1314ynh47KJj3 Ss=; b=ggBMK9q+GAPR55u7H/KbQJDimkwRstsiDocj5xT9yJpqjWlLOnSvpDYOt 2KyQPvrFKkOXq/JSrrlpSMjAG+g8bIdM+7BwHCVOtXbkS+i/VBYH7N2COOyOsthY s6hA8265GfAHY80rPSPcWBlq5Jk22isyFgSv/nYIpXtqWEeioMktdosegI8gopjx gm64lIL5zE+iVlS7/st2I20YfszlrxMqg9hc/f6rVAqybjA4PwB+PE1s5cKjCsKG qBS/UXoG6NtADgm3J5/+Rwl4GROsmT0xzmPB2KRwtIXnNgQ136m6YUUpnTPEo0tZ 0u/Zn2QChCxSkh1e7kenYGDBltB1Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeeggddutdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 33FDB30600A3; Thu, 16 Jul 2020 12:42:42 -0400 (EDT) From: Thomas Monjalon To: Honnappa Nagarahalli , Phil Yang Cc: "dev@dpdk.org" , "Mcnamara, John" , David Christensen , dev , "jerinj@marvell.com" , "Ananyev, Konstantin" , Ola Liljedahl , Bruce Richardson , Ruifeng Wang , nd , David Marchand , nd Date: Thu, 16 Jul 2020 18:42:40 +0200 Message-ID: <4777511.sDcrFEcvGN@thomas> In-Reply-To: References: <1594621423-14796-1-git-send-email-phil.yang@arm.com> <3325015.uBoaBXitGU@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v8 2/3] devtools: prevent use of rte atomic APIs in future patches 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" 16/07/2020 18:37, Phil Yang: > Hello, > > Thomas Monjalon writes: > > > Subject: Re: [dpdk-dev] [PATCH v8 2/3] devtools: prevent use of rte atomic > > APIs in future patches > > > > 16/07/2020 12:48, David Marchand: > > > On Thu, Jul 16, 2020 at 6:58 AM Phil Yang wrote: > > > > check_forbidden_additions() { # > > > > res=0 > > > > + c11_atomics_dir="lib/librte_distributor lib/librte_hash lib/librte_kni > > > > + lib/librte_lpm lib/librte_rcu lib/librte_ring > > > > + lib/librte_stack lib/librte_vhost > > > > + drivers/event/octeontx drivers/event/octeontx2 > > > > + drivers/event/opdl drivers/net/bnx2x drivers/net/hinic > > > > + drivers/net/hns3 drivers/net/memif drivers/net/thunderx > > > > + drivers/net/virtio examples/l2fwd-event" > > > > > > I prefer a form like: > > > > > > + c11_atomics_dir="" > > > + c11_atomics_dir="$c11_atomics_dir drivers/event/octeontx" > > > + c11_atomics_dir="$c11_atomics_dir drivers/event/octeontx2" > > > + c11_atomics_dir="$c11_atomics_dir drivers/event/opdl" > > > + c11_atomics_dir="$c11_atomics_dir drivers/net/bnx2x" > > > + c11_atomics_dir="$c11_atomics_dir drivers/net/hinic" > > > + c11_atomics_dir="$c11_atomics_dir drivers/net/hns3" > > > + c11_atomics_dir="$c11_atomics_dir drivers/net/memif" > > > + c11_atomics_dir="$c11_atomics_dir drivers/net/thunderx" > > > + c11_atomics_dir="$c11_atomics_dir drivers/net/virtio" > > > + c11_atomics_dir="$c11_atomics_dir examples/l2fwd-event" > > > + c11_atomics_dir="$c11_atomics_dir lib/librte_distributor" > > > + c11_atomics_dir="$c11_atomics_dir lib/librte_hash" > > > + c11_atomics_dir="$c11_atomics_dir lib/librte_kni" > > > + c11_atomics_dir="$c11_atomics_dir lib/librte_lpm" > > > + c11_atomics_dir="$c11_atomics_dir lib/librte_rcu" > > > + c11_atomics_dir="$c11_atomics_dir lib/librte_ring" > > > + c11_atomics_dir="$c11_atomics_dir lib/librte_stack" > > > + c11_atomics_dir="$c11_atomics_dir lib/librte_vhost" > > > > > > Easier to read and update. > > > > Why do we need this list at all? > > Are we allowed to add new code with old atomics > > in other directories? > > How bad it is to have a warning on non-converted libs? > > From my perspective, the pros of this list are : > 1. Avoid introducing false warnings in non-converted modules. Otherwise, the maintainers have to wonder if that module is converted or not. Don't we want to convert all libs? If we are adding one more rte_atomic in a lib, we should ask the question why not converting to C11, no? > 2. Keep non-converted modules compatible. C11 atomic builtins cannot be used directly for rte_atomicXX_t variables. > > The cons are : > 1. The list needs updating every time we convert a module. > 2. The script is not elegant as before.