From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 303DBA00E6 for ; Mon, 15 Apr 2019 20:56:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C958C1B227; Mon, 15 Apr 2019 20:56:07 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140087.outbound.protection.outlook.com [40.107.14.87]) by dpdk.org (Postfix) with ESMTP id 2B5111B20A for ; Mon, 15 Apr 2019 20:56:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O8XHMg5+PMeAcF1kAdLh2L1yYugf2R6ROmgarquL4zc=; b=gqsFFXtaY58b2fisDyI/BKUGa2udd08wp9GI8dkfLdC8Erin74duQhAWo1BV7uh8eCwbhkGoKxNNOQH5Smo4Q4pT7/p5l4hkQMDvUXabl3jnt64nFIGdWBkn+HpTCaZBRfiWCqXCD1p3HFdws0DtYmpFTmW5IMY486hDVx4ptlI= Received: from VE1PR08MB5149.eurprd08.prod.outlook.com (20.179.30.152) by VE1PR08MB4655.eurprd08.prod.outlook.com (10.255.27.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.15; Mon, 15 Apr 2019 18:56:04 +0000 Received: from VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::e0ae:ecad:ec5:8177]) by VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::e0ae:ecad:ec5:8177%2]) with mapi id 15.20.1792.018; Mon, 15 Apr 2019 18:56:05 +0000 From: Honnappa Nagarahalli To: "Ananyev, Konstantin" , Stephen Hemminger CC: "paulmck@linux.ibm.com" , "Kovacevic, Marko" , "dev@dpdk.org" , "Gavin Hu (Arm Technology China)" , Dharmik Thakkar , Malvika Gupta , Honnappa Nagarahalli , nd , nd Thread-Topic: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism Thread-Index: AQHU8XwL9ZW9vcwT20K3DuZSwCCMIqY5FWOAgAAQXYCABAO1gIAANiQAgAAhr4CAABS64A== Date: Mon, 15 Apr 2019 18:56:05 +0000 Message-ID: References: <20181122033055.3431-1-honnappa.nagarahalli@arm.com> <20190412202039.46902-1-honnappa.nagarahalli@arm.com> <20190412202039.46902-2-honnappa.nagarahalli@arm.com> <20190412150650.3709358e@shemminger-XPS-13-9360> <20190412160629.670eacd1@shemminger-XPS-13-9360> <2601191342CEEE43887BDE71AB9772580148A97E53@irsmsx105.ger.corp.intel.com> <20190415083834.31b38ed3@shemminger-XPS-13-9360> <2601191342CEEE43887BDE71AB9772580148A98064@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580148A98064@irsmsx105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Honnappa.Nagarahalli@arm.com; x-originating-ip: [217.140.111.135] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54bb2c18-1e45-458f-1c21-08d6c1d4037c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VE1PR08MB4655; x-ms-traffictypediagnostic: VE1PR08MB4655: x-ms-exchange-purlcount: 1 nodisclaimer: True x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(396003)(376002)(39860400002)(136003)(189003)(199004)(74316002)(3846002)(305945005)(7736002)(5660300002)(6116002)(7696005)(8676002)(52536014)(2906002)(186003)(93886005)(105586002)(110136005)(106356001)(316002)(8936002)(68736007)(97736004)(81166006)(81156014)(76176011)(6506007)(102836004)(26005)(86362001)(25786009)(53936002)(71190400001)(476003)(54906003)(33656002)(446003)(66066001)(71200400001)(14454004)(6436002)(55016002)(11346002)(14444005)(72206003)(229853002)(966005)(9686003)(6306002)(6246003)(478600001)(256004)(4326008)(99286004)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR08MB4655; H:VE1PR08MB5149.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4t5YpctntWUVbED+k51CrS71n6GBBeKeWACRu+5WUPDv+xKptxyYW8CrBqJMH7g4yowpqM8EhdimbPuBGYdlGIGIF6+aSW6fREa1R5eamptp+yj2OKqiZnnptsToYDgwTbwsYLXRfYVMqlzO5MfGX2z70uiEtl7XI8jE8FmYiCDm5cOLZvOzmncjwHKo5fYUHVooSldXtun3aQie8LqOIJaza9jcSrV2Jg0Z4+IZJM9OB1+q5gWSXCDRThiQjECi5xUzG+kuJsFcfDUpGQy9OJgLIs/Z7BkfDPJBeKhIl4Pla0o+DK4YfDh2KE/OKDYjWtKmRDFSjbkXpvuFhEByMycuhiNySsDgeRbZAeptZXwAoEX1mMbbnjzTnGEYXWdDLlvD/M2DSQw1BzmfEfHZYD+QJ8NH67oBq+b47JUTY+o= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 54bb2c18-1e45-458f-1c21-08d6c1d4037c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 18:56:05.4145 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB4655 Subject: Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism 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" Message-ID: <20190415185605.cRmgK_BF06bfeMqFsViOYUIOFrCvMuEwxUmeXz4WZY0@z> > > > > > > > > > > > > After evaluating long term API/ABI issues, I think you need to > > > > > > get rid of almost all use of inline and visible structures. > > > > > > Yes it might be marginally slower, but you thank me the first t= ime > you have to fix something. > > > > > > > > > > > Agree, I was planning on another version to address this (I am ye= t > to take a look at your patch addressing the ABI). > > > > > The structure visibility definitely needs to be addressed. > > > > > For the inline functions, is the plan to convert all the inline > > > > > functions in DPDK? If yes, I think we need to consider the > > > > > performance > > > > difference. May be consider L3-fwd application, change all the inli= ne > functions in its path and run a test? > > > > > > > > Every function that is not in the direct datapath should not be inl= ine. > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and > > > > packet alloc/free > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc. > > > I think rcu should be one of such exceptions - it is just another > > > synchronization mechanism after all (just a bit more sophisticated). > > > Konstantin > > > > If you look at the other userspace RCU, you wil see that the only > > inlines are the rcu_read_lock,rcu_read_unlock and > rcu_reference/rcu_assign_pointer. > > > > The synchronization logic is all real functions. >=20 > In fact, I think urcu provides both flavors: > https://github.com/urcu/userspace- > rcu/blob/master/include/urcu/static/urcu-qsbr.h > I still don't understand why we have to treat it differently then let say > spin-lock/ticket-lock or rwlock. > If we gone all the way to create our own version of rcu, we probably want > it to be as fast as possible (I know that main speedup should come from > the fact that readers don't have to wait for writer to finish, but still.= ..) >=20 Except for ' rte_rcu_qsbr_synchronize' (will correct in the next version), = we have the correct APIs marked as inline. They all are part of the fast pa= th. > Konstantin