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 5FC21A0527; Sat, 18 Jul 2020 04:18:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2E8101BF7E; Sat, 18 Jul 2020 04:18:40 +0200 (CEST) Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by dpdk.org (Postfix) with ESMTP id 2F4F81BF70 for ; Sat, 18 Jul 2020 04:18:39 +0200 (CEST) Received: by mail-pf1-f194.google.com with SMTP id x72so6239582pfc.6 for ; Fri, 17 Jul 2020 19:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=87Rq0gi3zsD0cZqGfCMxb0JZwQ7GGOJeAjiFwsq3gq4=; b=apgVzTNQNwCjPV9PzulrgSMmoxEyPKP2CaEKdOjtKTgK8th1s9fNvUOgIFpl6qc12g m7obpiTwCWFRRQztT3v8uJba2VJR1rQp/SRWm0i4l7UEPZz9FjJ8Q2dqrtE3ajXPBpMq zBRWXJ1klceelhqXub9GKtM7MAuesVN6I3Jj04z+K6odmXMUX1zlbGGV+Qmdv41gzqtB s388QY2BLu+O8BAVPXRiP2wGA94JH61DauZeUVyTBtDQoGCYjY7bn8+dpb64hyjRxVA7 cKE2JJ0xIuJFl7dHdTZtqr2On1E6S6OrerU0GEV0OvZV6tFgOuNhZV7/atugcAqlWMy6 Lp6Q== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=87Rq0gi3zsD0cZqGfCMxb0JZwQ7GGOJeAjiFwsq3gq4=; b=EqLkUCxHJgAD6cOONcBMiuQ/H+76yGtXL8Su+RHa8pSA6YiAr36mLRIafW8Tq0SC03 E/II3sLvFUxOTKQ7r8OgPKpInq9M6oDvpXbTR5f+DTCdKwGXHYltjsZDTWoH/aQigDDl v8ucF1Xz7dKQhJIVn9WpazUYhr/1vyAQ4iYTiOsOuOvI9PI8vwsjyersCEkk1okq/M9N sGukuENROMGuV8OqgRwUp39UrLQU/htTOy298syKMVwgdtCNBa9WVfm4ysrAcQfPVneZ aTwG7Ctw8yhmv94emxQYzKTQ7xQaylOr2eQ8UJ1cq8GRH4wwvmgN6lEAm+eqCRRncvGF GVdQ== X-Gm-Message-State: AOAM532ylh3zXRAmQ089N0OGCUH93c/Bv0jLwibg9DdB0gxLPJ47ewZ5 PETxIa1SpI9EVLU69V1pzyxMxw== X-Google-Smtp-Source: ABdhPJwEebbR6VW8FbK5W/8Fj3ap3QE28KO5+03hVMXpDEqEcBMA+UzePeXLSJlJZv+qYAUm2Hmh0A== X-Received: by 2002:a63:225d:: with SMTP id t29mr11403231pgm.374.1595038718224; Fri, 17 Jul 2020 19:18:38 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id k63sm9168084pge.0.2020.07.17.19.18.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2020 19:18:37 -0700 (PDT) Date: Fri, 17 Jul 2020 19:18:28 -0700 From: Stephen Hemminger To: Honnappa Nagarahalli Cc: "thomas@monjalon.net" , Phil Yang , "dev@dpdk.org" , "Mcnamara, John" , David Christensen , "jerinj@marvell.com" , "Ananyev, Konstantin" , Ola Liljedahl , Bruce Richardson , Ruifeng Wang , nd , David Marchand Message-ID: <20200717191828.0ccbc9c3@hermes.lan> In-Reply-To: References: <1594621423-14796-1-git-send-email-phil.yang@arm.com> <3325015.uBoaBXitGU@thomas> <4777511.sDcrFEcvGN@thomas> <20200716144552.12d384c7@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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" On Fri, 17 Jul 2020 22:48:04 +0000 Honnappa Nagarahalli wrote: > > > > Don't we want to convert all libs? > > > The goal is to convert all the libs. > > > > > > > If we are adding one more rte_atomic in a lib, we should ask the > > > > question why not converting to C11, no? > > > Agree, I am fine with this approach. That will kind of distribute the > > conversion work as well. > > > > > > > > > > > > 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. > > > This list will go away once all the modules are converted. > > > > > > > > 2. The script is not elegant as before. > > > > > > > > > > > > > > > Can't the conversion just be automated with something coccinelle? > I do not know what 'coccinelle' means, not much help on the internet as well. > > I really have not thought about automation. But, working on these conversions, I have realized that understanding of the synchronizations used is required (basically, understanding the entire module) to ensure the correct barriers are used. We could use the most strongest barrier and functionality would be fine, but the performance would take a hit. coccinelle is a semantic patch tool, it allows for changes that are know how to deal with arguments to functions etc. It is widely used in Linux kernel to do tree wide changes (for example adding a new argument to an internal function). https://www.kernel.org/doc/html/latest/dev-tools/coccinelle.html