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 4632FA057B; Wed, 18 Mar 2020 15:01:35 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3FCBA1AFF; Wed, 18 Mar 2020 15:01:34 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id E3AD1FEB for ; Wed, 18 Mar 2020 15:01:32 +0100 (CET) IronPort-SDR: 1vYYlSjRqFz1M8JJM8xW6ve0hhV/Jg93AV4GzC15MMKupwQtquTXX7mMLwHBQXlIh1Ue+guHhl xzNtqYyG3Utg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2020 07:01:32 -0700 IronPort-SDR: D1aBLbsMVUb2kZwLsIZkggBcaGj9zglFhUIK92HG0Od4dVe4hlRlgFeATZVwtuUNHFb5vNSj6F ByWMbyBPk37Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,567,1574150400"; d="scan'208";a="238615123" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga008.jf.intel.com with ESMTP; 18 Mar 2020 07:01:31 -0700 Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 18 Mar 2020 07:01:31 -0700 Received: from ORSEDG002.ED.cps.intel.com (10.7.248.5) by ORSMSX155.amr.corp.intel.com (10.22.240.21) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 18 Mar 2020 07:01:31 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.42) by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 18 Mar 2020 07:01:31 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kkca1x89mwTk5PQYdTXZODu+maX/iXZsB+1gKmf+TmxhRC4M7afeJHMnKNCOF65GZkDkn1nBEk7q9QsZtXDzAALbfAeIkxi+ixCN+ui0ffhuFIDvtvgR6qTLXQchQPL73XCOuH3mXasZkVPQ96DJ8PivFiXsOvmI6QdhSY0t1lPbrOwOFBtfXjDLPYSxYpBj26Ub47QvAjlV8rJ4DWmJ7wSCGH19rl9u/fOx60wMQjymYcEyyvsFGfKwsxeZ4Ra11kQ53z8PjzhEjkGqUg8EoiMZCO2F1VUO+uL6iTCQ/BcThFor01noMakxxN54mWXDqY061/R9jToe7e+fSPj+bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QvvYAx5lci8pb0TpW0jnvddSCBGraU2uL5xC1XqgDFc=; b=Z8aVBPJMegXa/IQfN/oCJw59t/qcjEWNlZiwJzr/7GbxvpwnHCGWt8/3PfGa2Q7qhIPct9ZMD/xbcwz5sHXws/A5QuWXIu3H0D/rGELpeenxIklkpJcTt18z5sGtArjEzX6sn+Vau1cvghFk7/iMuAPtmWgVBsTme3dXO0cGjDGWl7DUkio2nnFoQ7F2gRjhM/9iKHCpqSifmlOexjCvxt1wKcSaWmce2Bnp9Gsu2rmpRQrn2S6/FxqWh8UfczxLtMkMsrxBvPsHAvne/xybpdcXH4c/XaRWPTYgDw9Ku6oZewCOiTXF6OkKxbrM+6uTFmgMR0b5yIre6qU+SGvIjw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QvvYAx5lci8pb0TpW0jnvddSCBGraU2uL5xC1XqgDFc=; b=mZnsXF9VgMkVNXPeEeJ6tMeV6Kxp8XgLLnIxMvGZIjrNwBP7lgC+cjUEr4c8ZllM5aKi8C+lodLVeI0xk1lLhM0FT0xzRg9+UmQ2A7flaFsrxcUay0cL8+nfEH37qTKikyc022BdCUC15wJtCqFe1vZzIzmu9Ghrp+OlBKiaRbg= Received: from MWHPR1101MB2157.namprd11.prod.outlook.com (2603:10b6:301:51::10) by MWHPR1101MB2286.namprd11.prod.outlook.com (2603:10b6:301:5b::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.19; Wed, 18 Mar 2020 14:01:29 +0000 Received: from MWHPR1101MB2157.namprd11.prod.outlook.com ([fe80::7d16:3f1d:52c9:3116]) by MWHPR1101MB2157.namprd11.prod.outlook.com ([fe80::7d16:3f1d:52c9:3116%5]) with mapi id 15.20.2835.017; Wed, 18 Mar 2020 14:01:29 +0000 From: "Van Haaren, Harry" To: Phil Yang , "thomas@monjalon.net" , "Ananyev, Konstantin" , "stephen@networkplumber.org" , "maxime.coquelin@redhat.com" , "dev@dpdk.org" CC: "david.marchand@redhat.com" , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , "Honnappa.Nagarahalli@arm.com" , "gavin.hu@arm.com" , "ruifeng.wang@arm.com" , "joyce.kong@arm.com" , "nd@arm.com" Thread-Topic: [PATCH v3 00/12] generic rte atomic APIs deprecate proposal Thread-Index: AQHV+/oHYvInwZkrnEm8WRIHQJ4aXqhOXJwQ Date: Wed, 18 Mar 2020 14:01:29 +0000 Message-ID: References: <1583999071-22872-1-git-send-email-phil.yang@arm.com> <1584407863-774-1-git-send-email-phil.yang@arm.com> In-Reply-To: <1584407863-774-1-git-send-email-phil.yang@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 authentication-results: spf=none (sender IP is ) smtp.mailfrom=harry.van.haaren@intel.com; x-originating-ip: [192.198.151.174] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dbb6506c-7369-428a-63eb-08d7cb44db67 x-ms-traffictypediagnostic: MWHPR1101MB2286: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(199004)(2906002)(86362001)(54906003)(110136005)(33656002)(53546011)(6506007)(7696005)(8936002)(8676002)(498600001)(7416002)(81156014)(81166006)(66476007)(76116006)(5660300002)(66946007)(66556008)(64756008)(66446008)(52536014)(71200400001)(4326008)(26005)(9686003)(186003)(55016002)(41533002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR1101MB2286; H:MWHPR1101MB2157.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rNvYNHjpDoWVkcwAVdqn3xxhNl8Ar9qRAX3u74HnV/8x9P9L26HeT+lYoVs4opNnFrJMA6gqYmTWtStJ0ESu+8MnsBUl/o1B38+BirjihSB/J6EtoAddZwt6fowujlSmzIRsVO+2u+UY5QEBaYL8xkQLFHmRDOo2UdDAYNBByB66wLiqaeqmOpj11wWhX5N+fQ+dl2JeuUItBGHTs9j3HAm4OgkR1eO6p1xKJ7Gzuvsm0n2djl9spsyN/mSQpKjkx/LI6GFQnZHq2g1QKTmZ6fqwyp8CP0R9rGJCzvx2wXHyVlFuCEzxGqlyj/2G7d9ptIZiGyj6n3bCWBRoV3oT09X5w2D/H9GeMdtVOBzH38KgCehLOJ9ItZKvdaD668nK4gjaipS3GJHVp5xAEb/xMNeCJCIOLY05NSEBnjPS+0CowJkP4d0K1Q9lPI12SoSX/FBqxAm/GU+uCPSYkwM1ufZKfG/UtcT/IoimY9oQ75wCJrc2+zn2o42aMl4aQRW3 x-ms-exchange-antispam-messagedata: huh+qzN92QFADqEESGR7SPrLsrPYHCX/zwVCUR2Lu11TTvb8LIe+KsWUCFbmGbEHFBlGb6GhK3uvMbfRr4+F/f689yUagZdwkdvCBfescdBIQzueCt15ZnCCrhIjhEanauKqYpWnPCF0csGK+ihtzw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dbb6506c-7369-428a-63eb-08d7cb44db67 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2020 14:01:29.3995 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HTMSOGD5w8fYEjRWQ1D7fGCAYQUNBOIMY6d5yEOtqVicXvEKx6BETTOP/xi+5nEFeD1Xo2Sypemz1BurfB3UmLmHjkMnJMDpKQDaP+PVgj0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2286 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3 00/12] generic rte atomic APIs deprecate proposal 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" Hi Phil & Honnappa, > -----Original Message----- > From: Phil Yang > Sent: Tuesday, March 17, 2020 1:18 AM > To: thomas@monjalon.net; Van Haaren, Harry ; > Ananyev, Konstantin ; > stephen@networkplumber.org; maxime.coquelin@redhat.com; dev@dpdk.org > Cc: david.marchand@redhat.com; jerinj@marvell.com; hemant.agrawal@nxp.com= ; > Honnappa.Nagarahalli@arm.com; gavin.hu@arm.com; ruifeng.wang@arm.com; > joyce.kong@arm.com; nd@arm.com > Subject: [PATCH v3 00/12] generic rte atomic APIs deprecate proposal >=20 > DPDK provides generic rte_atomic APIs to do several atomic operations. > These APIs are using the deprecated __sync built-ins and enforce full > memory barriers on aarch64. However, full barriers are not necessary > in many use cases. In order to address such use cases, C language offers > C11 atomic APIs. The C11 atomic APIs provide finer memory barrier control > by making use of the memory ordering parameter provided by the user. > Various patches submitted in the past [2] and the patches in this series > indicate significant performance gains on multiple aarch64 CPUs and no > performance loss on x86. >=20 > But the existing rte_atomic API implementations cannot be changed as the > APIs do not take the memory ordering parameter. The only choice available > is replacing the usage of the rte_atomic APIs with C11 atomic APIs. In > order to make this change, the following steps are proposed: >=20 > [1] deprecate rte_atomic APIs so that future patches do not use rte_atomi= c > APIs (a script is added to flag the usages). > [2] refactor the code that uses rte_atomic APIs to use c11 atomic APIs. On [1] above, I feel deprecating DPDKs atomic functions and failing checkpa= tch is a bit sudden. Perhaps noting that in a future release (20.11?) DPDK will mo= ve to a C11 based atomics model is a more gradual step to achieving the goal, and a= t that point add a checkpatch warning for additions of rte_atomic*? More on [2] in context below. The above is my point-of-view, of course I'd like more people from the DPDK= community to provide their input too. > This patchset contains: > 1) the checkpatch script changes to flag rte_atomic API usage in patches. > 2) changes to programmer guide describing writing efficient code for aarc= h64. > 3) changes to various libraries to make use of c11 atomic APIs. >=20 > We are planning to replicate this idea across all the other libraries, > drivers, examples, test applications. In the next phase, we will add > changes to the mbuf, the EAL interrupts and the event timer adapter libra= ries. About ~6/12 patches of this C11 set are targeting the Service Cores area of= DPDK. I have some concerns over increased complexity of C11 implementation vs the (already complex) rt= e_atomic implementation today. I see other patchsets enabling C11 across other DPDK components, so maybe w= e should also discuss C11 enabling in a wider context that just service cores? I don't think it fair to expect all developers to be well versed in C11 ato= mic semantics like understanding the complex interactions between the various C11 RELEASE, AQU= IRE barriers requires. As maintainer of Service Cores I'm hesitant to accept the large-scale refac= tor of atomic-implementation, as it could lead to racey bugs that are likely extremely difficult to track= down. (The recent race-on-exit has proven the difficulty in reproducing, and that's with an atomics model = I'm quite familiar with). Let me be very clear: I don't wish to block a C11 atomic implementation, bu= t I'd like to discuss how we (DPDK community) can best port-to and maintain a complex multi-threaded ser= vice library with best-in-class performance for the workload. To put some discussions/solutions on the table: - Shared Maintainership of a component? Split in functionality and C11 atomics implementation Obviously there would be collaboration required in such a case. - Maybe shared maintainership is too much? A gentlemans/womans agreement of "helping out" with C11 atomics debug = is enough? Hope my concerns are understandable, and of course input/feedback welcomed!= -Harry PS: Apologies for the delay in reply - was OOO on Irish national holiday. > v3: > add libatomic dependency for 32-bit clang >=20 > v2: > 1. fix Clang '-Wincompatible-pointer-types' WARNING. > 2. fix typos. >=20 > Honnappa Nagarahalli (2): > service: avoid race condition for MT unsafe service > service: identify service running on another core correctly >=20 > Phil Yang (10): > doc: add generic atomic deprecation section > devtools: prevent use of rte atomic APIs in future patches > eal/build: add libatomic dependency for 32-bit clang > build: remove redundant code > vhost: optimize broadcast rarp sync with c11 atomic > ipsec: optimize with c11 atomic for sa outbound sqn update > service: remove rte prefix from static functions > service: remove redundant code > service: optimize with c11 one-way barrier > service: relax barriers with C11 atomic operations >=20 > devtools/checkpatches.sh | 9 ++ > doc/guides/prog_guide/writing_efficient_code.rst | 60 +++++++- > drivers/event/octeontx/meson.build | 5 - > drivers/event/octeontx2/meson.build | 5 - > drivers/event/opdl/meson.build | 5 - > lib/librte_eal/common/rte_service.c | 175 ++++++++++++-----= ----- > - > lib/librte_eal/meson.build | 6 + > lib/librte_ipsec/ipsec_sqn.h | 3 +- > lib/librte_ipsec/sa.h | 2 +- > lib/librte_rcu/meson.build | 5 - > lib/librte_vhost/vhost.h | 2 +- > lib/librte_vhost/vhost_user.c | 7 +- > lib/librte_vhost/virtio_net.c | 16 ++- > 13 files changed, 181 insertions(+), 119 deletions(-) >=20 > -- > 2.7.4