From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50058.outbound.protection.outlook.com [40.107.5.58]) by dpdk.org (Postfix) with ESMTP id 845D41B460 for ; Tue, 16 Apr 2019 07:29:23 +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=iZtDIZ6GRZEGFcF1B8/8oQFvf0bCdEsdZzdQ4mY/4nU=; b=c3G5diONqIHnATK3gxXPAUZ+TlO3wsP8E5KlUS3zNEbPXVsnFCwD6pBDY6vKLDH6bFAh5/57stDql43QJZLu7VvyXAugFSFAY2ZCD1cWdes2DsBIHuaftW/CFA8hF/VAgs1Z7KnvmIUsy+p40J8EznOIZjZqFAyTee4+F9WhSQw= Received: from VE1PR08MB5149.eurprd08.prod.outlook.com (20.179.30.152) by VE1PR08MB5053.eurprd08.prod.outlook.com (10.255.159.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Tue, 16 Apr 2019 05:29:21 +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; Tue, 16 Apr 2019 05:29:21 +0000 From: Honnappa Nagarahalli To: Stephen Hemminger , "Ananyev, Konstantin" 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: AQHU8XwL9ZW9vcwT20K3DuZSwCCMIqY5FWOAgASrdlSAAIGtIA== Date: Tue, 16 Apr 2019 05:29:21 +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> <20190415142631.4c250248@shemminger-XPS-13-9360> In-Reply-To: <20190415142631.4c250248@shemminger-XPS-13-9360> 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: f5716467-7735-49b7-9af3-08d6c22c7ab5 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:VE1PR08MB5053; x-ms-traffictypediagnostic: VE1PR08MB5053: x-ms-exchange-purlcount: 2 nodisclaimer: True x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(366004)(39860400002)(376002)(396003)(199004)(189003)(8676002)(110136005)(186003)(66066001)(2906002)(97736004)(86362001)(5660300002)(11346002)(476003)(74316002)(478600001)(8936002)(4326008)(26005)(76176011)(446003)(256004)(54906003)(486006)(316002)(305945005)(72206003)(7736002)(14444005)(6306002)(53936002)(14454004)(229853002)(966005)(105586002)(71200400001)(99286004)(81156014)(81166006)(68736007)(71190400001)(93886005)(55016002)(52536014)(33656002)(6246003)(9686003)(3846002)(102836004)(6116002)(6506007)(7696005)(25786009)(6436002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR08MB5053; H:VE1PR08MB5149.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: 8FxZ2Hz122KnrbKpUEp/s9p9DGeegV43Kq7jRF4TL+6aJqy4L0ehwy9N2vUFjthYLDMMJpRHmBd5mvRxJGNb/Ng2wlwxE28xtH3hYlFDqGyPcd8AvNAVP+TCY9WHbl4hrcXpND41FW4KzW8M0RtGzpa90cYzIb6kNjsPl5CgXRw7T5buDn+E8TfRvOsEyC3/PAHux/3MmEg/5Yuo/rU6L9XBbTkwqyYvKmyCM59T2lfluD+ZcUc1WYLl0cKMr0JdTgycQ41pc2Jt46+pqMqhEb17SuX3Rd63g7gkqtf8Y1LA+5HLzuLzePt/EIV4gG43uicIq16Uq1LZX8gRhJn2R6AQuG1BjhTwIhUL4EA6C6ZTzuNfV9Zscv+S/PN2ygIZ53mCvgQ79MCw73UQwpoR6QRzVaUwfGtg8gFX8iaC+6k= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: f5716467-7735-49b7-9af3-08d6c22c7ab5 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 05:29:21.1344 (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: VE1PR08MB5053 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: , X-List-Received-Date: Tue, 16 Apr 2019 05:29:23 -0000 > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli > > > > > > > wrote: > > > > > > > > > > > > > > > Add RCU library supporting quiescent state based memory > > > > > > > > reclamation > > > > > > > method. > > > > > > > > This library helps identify the quiescent state of the > > > > > > > > reader threads so that the writers can free the memory > > > > > > > > associated with the lock less data structures. > > > > > > > > > > > > > > > > Signed-off-by: Honnappa Nagarahalli > > > > > > > > > > > > > > > > Reviewed-by: Steve Capper > > > > > > > > Reviewed-by: Gavin Hu > > > > > > > > Reviewed-by: Ola Liljedahl > > > > > > > > Acked-by: Konstantin Ananyev > > > > > > > > > > > > > > > > > > > > > > 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 time you have to fix something. > > > > > > > > > > > > > Agree, I was planning on another version to address this (I am = yet > 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 > inline functions in its path and run a test? > > > > > > > > > > Every function that is not in the direct datapath should not be > inline. > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and > > > > > packet alloc/free I do not understand how DPDK can claim ABI compatibility if we have inline = functions (unless we freeze any development in these inline functions forev= er). > > > > > > > > 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. > > > > 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...) > > > > Konstantin > > >=20 > Having locking functions inline is already a problem in current releases. > The implementation can not be improved without breaking ABI (or doing > special workarounds like lock v2) I think ABI and inline function discussion needs to be taken up in a differ= ent thread. Currently, I am looking to hide the structure visibility. I looked at your = patch [1], it is a different case than what I have in this patch. It is a p= retty generic use case as well (similar situation exists in other libraries= ). I think a generic solution should be agreed upon. If we have to hide the structure content, the handle to QS variable returne= d to the application needs to be opaque. I suggest using 'void *' behind wh= ich any structure can be used. typedef void * rte_rcu_qsbr_t; typedef void * rte_hash_t; But it requires typecasting. [1] http://patchwork.dpdk.org/cover/52609/ 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 0804FA00E6 for ; Tue, 16 Apr 2019 07:29:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BB3F11B462; Tue, 16 Apr 2019 07:29:24 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50058.outbound.protection.outlook.com [40.107.5.58]) by dpdk.org (Postfix) with ESMTP id 845D41B460 for ; Tue, 16 Apr 2019 07:29:23 +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=iZtDIZ6GRZEGFcF1B8/8oQFvf0bCdEsdZzdQ4mY/4nU=; b=c3G5diONqIHnATK3gxXPAUZ+TlO3wsP8E5KlUS3zNEbPXVsnFCwD6pBDY6vKLDH6bFAh5/57stDql43QJZLu7VvyXAugFSFAY2ZCD1cWdes2DsBIHuaftW/CFA8hF/VAgs1Z7KnvmIUsy+p40J8EznOIZjZqFAyTee4+F9WhSQw= Received: from VE1PR08MB5149.eurprd08.prod.outlook.com (20.179.30.152) by VE1PR08MB5053.eurprd08.prod.outlook.com (10.255.159.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Tue, 16 Apr 2019 05:29:21 +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; Tue, 16 Apr 2019 05:29:21 +0000 From: Honnappa Nagarahalli To: Stephen Hemminger , "Ananyev, Konstantin" 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: AQHU8XwL9ZW9vcwT20K3DuZSwCCMIqY5FWOAgASrdlSAAIGtIA== Date: Tue, 16 Apr 2019 05:29:21 +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> <20190415142631.4c250248@shemminger-XPS-13-9360> In-Reply-To: <20190415142631.4c250248@shemminger-XPS-13-9360> 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: f5716467-7735-49b7-9af3-08d6c22c7ab5 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:VE1PR08MB5053; x-ms-traffictypediagnostic: VE1PR08MB5053: x-ms-exchange-purlcount: 2 nodisclaimer: True x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(366004)(39860400002)(376002)(396003)(199004)(189003)(8676002)(110136005)(186003)(66066001)(2906002)(97736004)(86362001)(5660300002)(11346002)(476003)(74316002)(478600001)(8936002)(4326008)(26005)(76176011)(446003)(256004)(54906003)(486006)(316002)(305945005)(72206003)(7736002)(14444005)(6306002)(53936002)(14454004)(229853002)(966005)(105586002)(71200400001)(99286004)(81156014)(81166006)(68736007)(71190400001)(93886005)(55016002)(52536014)(33656002)(6246003)(9686003)(3846002)(102836004)(6116002)(6506007)(7696005)(25786009)(6436002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR08MB5053; H:VE1PR08MB5149.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: 8FxZ2Hz122KnrbKpUEp/s9p9DGeegV43Kq7jRF4TL+6aJqy4L0ehwy9N2vUFjthYLDMMJpRHmBd5mvRxJGNb/Ng2wlwxE28xtH3hYlFDqGyPcd8AvNAVP+TCY9WHbl4hrcXpND41FW4KzW8M0RtGzpa90cYzIb6kNjsPl5CgXRw7T5buDn+E8TfRvOsEyC3/PAHux/3MmEg/5Yuo/rU6L9XBbTkwqyYvKmyCM59T2lfluD+ZcUc1WYLl0cKMr0JdTgycQ41pc2Jt46+pqMqhEb17SuX3Rd63g7gkqtf8Y1LA+5HLzuLzePt/EIV4gG43uicIq16Uq1LZX8gRhJn2R6AQuG1BjhTwIhUL4EA6C6ZTzuNfV9Zscv+S/PN2ygIZ53mCvgQ79MCw73UQwpoR6QRzVaUwfGtg8gFX8iaC+6k= 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: f5716467-7735-49b7-9af3-08d6c22c7ab5 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 05:29:21.1344 (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: VE1PR08MB5053 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: <20190416052921.gMcvKuxzf2UdZQoX9O0lQQFBuFbuRob0GlUWSmCzRwE@z> > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli > > > > > > > wrote: > > > > > > > > > > > > > > > Add RCU library supporting quiescent state based memory > > > > > > > > reclamation > > > > > > > method. > > > > > > > > This library helps identify the quiescent state of the > > > > > > > > reader threads so that the writers can free the memory > > > > > > > > associated with the lock less data structures. > > > > > > > > > > > > > > > > Signed-off-by: Honnappa Nagarahalli > > > > > > > > > > > > > > > > Reviewed-by: Steve Capper > > > > > > > > Reviewed-by: Gavin Hu > > > > > > > > Reviewed-by: Ola Liljedahl > > > > > > > > Acked-by: Konstantin Ananyev > > > > > > > > > > > > > > > > > > > > > > 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 time you have to fix something. > > > > > > > > > > > > > Agree, I was planning on another version to address this (I am = yet > 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 > inline functions in its path and run a test? > > > > > > > > > > Every function that is not in the direct datapath should not be > inline. > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and > > > > > packet alloc/free I do not understand how DPDK can claim ABI compatibility if we have inline = functions (unless we freeze any development in these inline functions forev= er). > > > > > > > > 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. > > > > 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...) > > > > Konstantin > > >=20 > Having locking functions inline is already a problem in current releases. > The implementation can not be improved without breaking ABI (or doing > special workarounds like lock v2) I think ABI and inline function discussion needs to be taken up in a differ= ent thread. Currently, I am looking to hide the structure visibility. I looked at your = patch [1], it is a different case than what I have in this patch. It is a p= retty generic use case as well (similar situation exists in other libraries= ). I think a generic solution should be agreed upon. If we have to hide the structure content, the handle to QS variable returne= d to the application needs to be opaque. I suggest using 'void *' behind wh= ich any structure can be used. typedef void * rte_rcu_qsbr_t; typedef void * rte_hash_t; But it requires typecasting. [1] http://patchwork.dpdk.org/cover/52609/