From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Honnappa.Nagarahalli@arm.com>
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 <dev@dpdk.org>; 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 <Honnappa.Nagarahalli@arm.com>
To: Stephen Hemminger <stephen@networkplumber.org>, "Ananyev, Konstantin"
 <konstantin.ananyev@intel.com>
CC: "paulmck@linux.ibm.com" <paulmck@linux.ibm.com>, "Kovacevic, Marko"
 <marko.kovacevic@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "Gavin Hu (Arm
 Technology China)" <Gavin.Hu@arm.com>, Dharmik Thakkar
 <Dharmik.Thakkar@arm.com>, Malvika Gupta <Malvika.Gupta@arm.com>, Honnappa
 Nagarahalli <Honnappa.Nagarahalli@arm.com>, nd <nd@arm.com>, nd <nd@arm.com>
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: <VE1PR08MB5149AA5C4CAC61DB42E286CF98240@VE1PR08MB5149.eurprd08.prod.outlook.com>
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>
 <VE1PR08MB51497C4B9E164CD07AC6EB5298280@VE1PR08MB5149.eurprd08.prod.outlook.com>
 <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: <VE1PR08MB5053DC4AF13CA4BD7040859C98240@VE1PR08MB5053.eurprd08.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2019 05:29:23 -0000

> > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > <honnappa.nagarahalli@arm.com> 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
> > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > >
> > > > > > > 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: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by dpdk.space (Postfix) with ESMTP id 0804FA00E6
	for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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 <Honnappa.Nagarahalli@arm.com>
To: Stephen Hemminger <stephen@networkplumber.org>, "Ananyev, Konstantin"
 <konstantin.ananyev@intel.com>
CC: "paulmck@linux.ibm.com" <paulmck@linux.ibm.com>, "Kovacevic, Marko"
 <marko.kovacevic@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "Gavin Hu (Arm
 Technology China)" <Gavin.Hu@arm.com>, Dharmik Thakkar
 <Dharmik.Thakkar@arm.com>, Malvika Gupta <Malvika.Gupta@arm.com>, Honnappa
 Nagarahalli <Honnappa.Nagarahalli@arm.com>, nd <nd@arm.com>, nd <nd@arm.com>
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:
 <VE1PR08MB5149AA5C4CAC61DB42E286CF98240@VE1PR08MB5149.eurprd08.prod.outlook.com>
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>
 <VE1PR08MB51497C4B9E164CD07AC6EB5298280@VE1PR08MB5149.eurprd08.prod.outlook.com>
 <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: <VE1PR08MB5053DC4AF13CA4BD7040859C98240@VE1PR08MB5053.eurprd08.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Message-ID: <20190416052921.gMcvKuxzf2UdZQoX9O0lQQFBuFbuRob0GlUWSmCzRwE@z>

> > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > <honnappa.nagarahalli@arm.com> 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
> > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > >
> > > > > > > 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/