From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Honnappa.Nagarahalli@arm.com>
Received: from EUR02-AM5-obe.outbound.protection.outlook.com
 (mail-eopbgr00088.outbound.protection.outlook.com [40.107.0.88])
 by dpdk.org (Postfix) with ESMTP id 092091B42F
 for <dev@dpdk.org>; Wed, 28 Nov 2018 06:32:01 +0100 (CET)
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=yWmAw3TpeHkqHRJtDcDtJkcGSHjecqYkZh126je7dfk=;
 b=Ko0ByxhEt1FOulChYOgy2/4a9mhBZooD0+SVtw9Qv+5NhKUC8CfSbnGGkClUgpAxj+tZlyo709xQcaZ7LrD1ps87Li4yyQxcFUvH4qEuzJhfTmpSGVDV8qw01KVFvGkOxrg1CKRvJZrg26iW3999M/GItTMSCUqeejhfG6TAlPc=
Received: from AM6PR08MB3672.eurprd08.prod.outlook.com (20.177.115.29) by
 AM6PR08MB4119.eurprd08.prod.outlook.com (20.179.2.90) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.1361.14; Wed, 28 Nov 2018 05:31:57 +0000
Received: from AM6PR08MB3672.eurprd08.prod.outlook.com
 ([fe80::6194:f5dd:48dd:9b1c]) by AM6PR08MB3672.eurprd08.prod.outlook.com
 ([fe80::6194:f5dd:48dd:9b1c%2]) with mapi id 15.20.1361.019; Wed, 28 Nov 2018
 05:31:57 +0000
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>, Stephen Hemminger
 <stephen@networkplumber.org>
CC: "dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>, Dharmik Thakkar
 <Dharmik.Thakkar@arm.com>, Malvika Gupta <Malvika.Gupta@arm.com>, "Gavin Hu
 (Arm Technology China)" <Gavin.Hu@arm.com>, Honnappa Nagarahalli
 <Honnappa.Nagarahalli@arm.com>, nd <nd@arm.com>
Thread-Topic: [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library
Thread-Index: AQHUhqB8tEevwcHR9UqXBYKYUzkOUKVkOZ6AgABmmXA=
Date: Wed, 28 Nov 2018 05:31:56 +0000
Message-ID: <AM6PR08MB3672F16A8B729EF14E38A2D098D10@AM6PR08MB3672.eurprd08.prod.outlook.com>
References: <20181122033055.3431-1-honnappa.nagarahalli@arm.com>
 <20181127142803.423c9b00@xeon-e3>
 <E923DB57A917B54B9182A2E928D00FA65E31B1F7@IRSMSX102.ger.corp.intel.com>
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA65E31B1F7@IRSMSX102.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-microsoft-exchange-diagnostics: 1; AM6PR08MB4119;
 6:708vBL3BSvUe7NhskofoxZaSpIDTn9KGAVjcgf7tM671KdJXvqZNZTdESDK7RDL4bBRQ3xHvtA6cbG9y1Sgd/idjTliuacFyqiyGXSWwQpU4EZm2RDrxcNpW3G7pOjE98HMcx9ridP4wm0Heseo78w7sfDBae2XN38RWKwrWp2Z79hsBfc8X8ADDvD0tbFCCV6lUkrFkxu6gecMgyHsX2u0+T8xyWfFmvs8e68yN87ylxj1MBirQM5jZ66mIL75Pq/CC3ClMC2jGHCwcKAQlyev8kwkZ9x4YANrZCTQPpyEh7C0ndqPDdufGqCiU0VgcXVQJyOpqiVCWJaCQgWC1LDiC8KklB6nr+Vz4UCrWCoFNkhCcXZ01+c5iADZ2d7Bvx1PAbjh5di+qrIuNIqAAwz5Dt3oKKpgL5xxk65Afn86AOZeE4ky49f0jBVDmI0P4mQs+sK7iIRgc/7WuurLZzQ==;
 5:gsW2vT5Scx4hK7Lo0N76fShTwfLbyFuMxS+4Gbbgs8uH6QvKFErihqIolZSu5HtA/i/m6S3Kz8tX5ovEzhXymupBOqDYtPmAIa2cxy3AgIA4j+eWFsgKRxiMLiDIcAvAhuJ/NnAVwiD7Q5OVM0cgRdkiwU2ho+LVCFQSWAkQP5I=;
 7:UdDjAblqeXE0BnOGvewn4TtwRR0iyqU92nROzvmgfNDatihrFb0MNwTGpxYlUu+5SH4YSkICZ+WdCZJ+ar/qwCB72QIdi3rCuAf/4G7ZHMsaNvopdoJrckP8MArSOrFsdYUyDiDxr4AZ5v7mDS4tag==
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-ms-office365-filtering-correlation-id: 322bd4ba-e4c0-40f1-6df6-08d654f2d024
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0;
 RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020);
 SRVR:AM6PR08MB4119; 
x-ms-traffictypediagnostic: AM6PR08MB4119:
nodisclaimer: True
x-microsoft-antispam-prvs: <AM6PR08MB4119BCCEDDCB425199FF6B1598D10@AM6PR08MB4119.eurprd08.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
 RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231443)(944501410)(52105112)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095);
 SRVR:AM6PR08MB4119; BCL:0; PCL:0; RULEID:; SRVR:AM6PR08MB4119; 
x-forefront-prvs: 0870212862
x-forefront-antispam-report: SFV:NSPM;
 SFS:(10009020)(136003)(376002)(396003)(366004)(346002)(39860400002)(189003)(199004)(54906003)(2906002)(86362001)(478600001)(72206003)(5660300001)(33656002)(25786009)(110136005)(7736002)(305945005)(74316002)(316002)(14454004)(68736007)(97736004)(476003)(966005)(8936002)(3846002)(6116002)(8676002)(81166006)(81156014)(11346002)(446003)(486006)(55016002)(76176011)(6306002)(9686003)(26005)(186003)(6506007)(102836004)(71200400001)(71190400001)(66066001)(106356001)(229853002)(105586002)(256004)(14444005)(6436002)(6246003)(99286004)(53936002)(4326008)(7696005);
 DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4119;
 H:AM6PR08MB3672.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-microsoft-antispam-message-info: hETRXuCXXhjt7MQbrnQcGXkLGvnD6OB3zb8JHSydzz5/M9ZyoEcwhcfXH782+8d+j8iB+7ofgDcNuklk7Wf/ZCy6Xpi65rGLUf6zln4Teh+9m+8kV1dqVV2Qb/Fo7ui+Z/mprzH/YJTDJ/kA/3IfZLbCQgVTP4JS5QMFGLn+goL1b1cEsrPX3FYzUVwhYDxwT+s2mS37IXKeB5z69dopEqpA59KqMZSSRBO3sp+kmaWpsRH6hcI/1UG1SYQDCIZih6UKcfklVbZk3hJCkhPGr1Wz94ANeDpe/Z4HH4g+/6emDTeF5JqyJA88F6DexWIIq9Y9eB8L+jelELl8w2SQrCi7XSWK78G7boAcFedIoiE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
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: 322bd4ba-e4c0-40f1-6df6-08d654f2d024
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2018 05:31:56.9746 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4119
Subject: Re: [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library
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: Wed, 28 Nov 2018 05:32:02 -0000

> >
> > On Wed, 21 Nov 2018 21:30:52 -0600
> > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> >
> > > Lock-less data structures provide scalability and determinism.
> > > They enable use cases where locking may not be allowed (for ex:
> > > real-time applications).
> > >
>=20
> <snip detailed RFC commit messag>
>=20
> > > Dharmik Thakkar (1):
> > >   test/tqs: Add API and functional tests
> > >
> > > Honnappa Nagarahalli (2):
> > >   log: add TQS log type
> > >   tqs: add thread quiescent state library
> > >
> > >  config/common_base                      |   6 +
> > >  lib/Makefile                            |   2 +
> > >  lib/librte_eal/common/include/rte_log.h |   1 +
> > >  lib/librte_tqs/Makefile                 |  23 +
> > >  lib/librte_tqs/meson.build              |   5 +
> > >  lib/librte_tqs/rte_tqs.c                | 249 +++++++++++
> > >  lib/librte_tqs/rte_tqs.h                | 352 +++++++++++++++
> > >  lib/librte_tqs/rte_tqs_version.map      |  16 +
> > >  lib/meson.build                         |   2 +-
> > >  mk/rte.app.mk                           |   1 +
> > >  test/test/Makefile                      |   2 +
> > >  test/test/autotest_data.py              |   6 +
> > >  test/test/meson.build                   |   5 +-
> > >  test/test/test_tqs.c                    | 540 ++++++++++++++++++++++=
++
> > >  14 files changed, 1208 insertions(+), 2 deletions(-)  create mode
> > > 100644 lib/librte_tqs/Makefile  create mode 100644
> > > lib/librte_tqs/meson.build  create mode 100644
> > > lib/librte_tqs/rte_tqs.c  create mode 100644
> > > lib/librte_tqs/rte_tqs.h  create mode 100644
> > > lib/librte_tqs/rte_tqs_version.map
> > >  create mode 100644 test/test/test_tqs.c
> > >
> >
> > Mixed feelings about this one.
> >
> > Love to see RCU used for more things since it is much better than
> > reader/writer locks for many applications. But hate to see DPDK
> > reinventing every other library and not reusing code. Userspace RCU
> > https://liburcu.org/ is widely supported by distro's, more throughly
> > tested and documented, and more flexiple.
> >
> > The issue with many of these reinventions is a tradeoff of DPDK
> > growing another dependency on external library versus using common code=
.
> >
Agree with the dependency issues. Sometimes flexibility also causes confusi=
on and features that are not necessarily required for a targeted use case. =
I have seen that much of the functionality that can be left to the applicat=
ion is implemented as part of the library.
I think having it in DPDK will give us control over the amount of capabilit=
y this library will have and freedom over changes we would like to make to =
such a library. I also view DPDK as one package where all things required f=
or data plane development are available.

> > For RCU, the big issue for me is the testing and documentation of how
> > to do RCU safely. Many people get it wrong!
Hopefully, we all will do a better job collectively :)

>=20
>=20
> Some notes on liburcu (and my amateur understanding of LGPL, I'm not a
> license lawyer :)
>=20
> Liburcu is LGPL, which AFAIK means we must dynamically link applications =
if
> the application code is BSD or other permissive licenses.
>=20
> The side effect of this is that urcu function calls must be "real" functi=
on calls
> and inlining them is not possible. Therefore using liburcu in LGPL mode c=
ould
> have a performance impact in this case. I expect estimating the performan=
ce
> cost would be
> difficult as its pretty much a case-by-case depending on what you're doin=
g in
> the surrounding code.
>=20
> Generally I'm in favour of using established libraries (particularly for =
complex
> functionality like RCU) but in this case I think there's a tradeoff with =
raw
> performance.