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 1ED2DA0577; Tue, 14 Apr 2020 17:58:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 06DE51C2AC; Tue, 14 Apr 2020 17:58:23 +0200 (CEST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2085.outbound.protection.outlook.com [40.107.21.85]) by dpdk.org (Postfix) with ESMTP id 47E371C2AC for ; Tue, 14 Apr 2020 17:58:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zwkehJ/VMBciiFJr8GMhxUBsvC2gxeAOP+AKo+GL+GM=; b=0f7oHy8DEoyTVVLU4UgXFJZY0uKwPi+0wNe9x1E5Pb/d6EtASJ29sytojn9+jrnaP/TZPfPjKwTqjVwueobwd67oDRbnwDX7qR7pPJyTQm0VwV/F/oC3zgoH6BxpNZA5Sh9mInclfr7U5sLMIXmaM2GR33cCxqAvGmZqRk+hB34= Received: from DB7PR05CA0004.eurprd05.prod.outlook.com (2603:10a6:10:36::17) by AM0PR08MB5041.eurprd08.prod.outlook.com (2603:10a6:208:162::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.20; Tue, 14 Apr 2020 15:58:20 +0000 Received: from DB5EUR03FT035.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:36:cafe::c3) by DB7PR05CA0004.outlook.office365.com (2603:10a6:10:36::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Tue, 14 Apr 2020 15:58:20 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dpdk.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dpdk.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT035.mail.protection.outlook.com (10.152.20.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Tue, 14 Apr 2020 15:58:19 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Tue, 14 Apr 2020 15:58:19 +0000 X-CR-MTA-TID: 64aa7808 Received: from 8caa321639d2.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 69DF4669-4C76-4C31-98CF-5F542901E89A.1; Tue, 14 Apr 2020 15:58:14 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 8caa321639d2.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 14 Apr 2020 15:58:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WjOvxuqHieBUUKbJvrL3rUzwkaUCxFhQPA09v23Ow/eZ9wF8D8pezTaYTIHqQpJOdxLFi4wy/kHiJof9GazsL7PfCTKQsoBYbxy2J5kfj9jAyNwt3f5PoxA0/+//TYVdy5WdWHvUvoohOK9BAWjmn0Ln0rO3UEm8f9fpIrLaZ+cgGA39xY8IGFQRp2rr6Rs7VIItLZ0601fvhgOcM59G6lhN5j4oOcerbmURKYexbn8Axv7Up1K6Z3hZ5Lwlrovgfz8y0fxHmfpOjFlv2DXCPCYknPCcNbS2S8JKV03zypzuJ2DE8SxTmeuFkN9+RrvUqSnbartphjL7bQyg7VuY/A== 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=zwkehJ/VMBciiFJr8GMhxUBsvC2gxeAOP+AKo+GL+GM=; b=jWO84b/ZkdfOoyJhOeMu+k/QcTmiPkJJQAxlYvCzDMQOUr73VY49Vu7Ikpeoc2y/7RHAKKC9Eo4aLFbqwfdbo4WBKBVXnuy2t1XCH+VuJQ0e4M5cA8S1utMteE5dzN8b++cabbf7UcnN7iv2cY5QwdXBlIszvhskqjkpBAoqbBdcVRfMIQjMtJXLt2rAeiayVrI5JiqpcVqGV+blRxl0evk4LE/CHbA2KHnDVvaTcdIUrb5zoFilO2+gV3l5L7uWMA2qvDO3HffJifOYP7VKs7Bx/1ql/qYT45XD5dOeqUtf3lYyfP3XbFG8kaIOLISovqJHPWnOjpcQso61y0/2PQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zwkehJ/VMBciiFJr8GMhxUBsvC2gxeAOP+AKo+GL+GM=; b=0f7oHy8DEoyTVVLU4UgXFJZY0uKwPi+0wNe9x1E5Pb/d6EtASJ29sytojn9+jrnaP/TZPfPjKwTqjVwueobwd67oDRbnwDX7qR7pPJyTQm0VwV/F/oC3zgoH6BxpNZA5Sh9mInclfr7U5sLMIXmaM2GR33cCxqAvGmZqRk+hB34= Received: from DBBPR08MB4646.eurprd08.prod.outlook.com (2603:10a6:10:f5::16) by DBBPR08MB4903.eurprd08.prod.outlook.com (2603:10a6:10:df::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.26; Tue, 14 Apr 2020 15:58:13 +0000 Received: from DBBPR08MB4646.eurprd08.prod.outlook.com ([fe80::1870:afc4:b90f:609d]) by DBBPR08MB4646.eurprd08.prod.outlook.com ([fe80::1870:afc4:b90f:609d%5]) with mapi id 15.20.2900.028; Tue, 14 Apr 2020 15:58:13 +0000 From: Honnappa Nagarahalli To: "Ananyev, Konstantin" , "dev@dpdk.org" CC: "david.marchand@redhat.com" , "jielong.zjl@antfin.com" , nd , Honnappa Nagarahalli , nd Thread-Topic: [PATCH v3 3/9] ring: introduce RTS ring mode Thread-Index: AQHWCd9WRTTZTeHr3kKWZbgjl/2b76huljRQgAJS+oCAAgY3UIAFu04AgAAqtiA= Date: Tue, 14 Apr 2020 15:58:13 +0000 Message-ID: References: <20200402220959.29885-1-konstantin.ananyev@intel.com> <20200403174235.23308-1-konstantin.ananyev@intel.com> <20200403174235.23308-4-konstantin.ananyev@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: e832eaa2-743a-43c4-a9fa-7e070c7a6108.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Honnappa.Nagarahalli@arm.com; x-originating-ip: [70.113.25.165] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: dfaf678c-d072-4d83-cc4d-08d7e08ca71b x-ms-traffictypediagnostic: DBBPR08MB4903:|DBBPR08MB4903:|AM0PR08MB5041: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6790;OLM:6790; x-forefront-prvs: 0373D94D15 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB4646.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(396003)(366004)(39860400002)(346002)(376002)(478600001)(52536014)(7696005)(6506007)(8676002)(186003)(4326008)(2906002)(26005)(33656002)(71200400001)(66946007)(64756008)(316002)(66446008)(5660300002)(86362001)(76116006)(66556008)(54906003)(8936002)(66476007)(81156014)(9686003)(110136005)(55016002)(21314003); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 6M+qw0wgx1dfdJht7nCPBlnXKVe2wFrubmBUBszdCqCOJmtZMwOuKboT2LRVYAc9Gt3dv4umJ9XsO3Kgn4d6QHfgsI2DmZOwtdzzD+mgr64oxmfqzbuL00SfDXY1GZ1nPjiwUtycPEQUneOEkkDb4zCTba33E6t0VB8hEAAwIYDNiBiuod3r69rlbs393QdRn48oGnKoLpomAgbPAwwU6n5UKsz0H7uXUXRRXXa61gl5uNuPlsPNdmms8Zj9HX9Tp9zr8PpN7i95fmB0Ijyncj4ZCOMFov9+0pv+ene21eh7l7rfL5RTEOT0VNVOSjTgv8X4QfVM9Ivg27jja+PdzXKyzQwJ3Yr/gvTldVX0uiyNGOf2TFH4BTh8u58LgtKQgIKY4vZ7f9xGGCPE5C8dErJsbYdsIJ6+G06gKuM8qSyrbM9VuhKRV2gMKgmCFzEg5g8yDNvIrkOJ3pLUIEzVMldNdJebku491fqf1S7qofCo3Df3nDIVF+yULEJLCDEx x-ms-exchange-antispam-messagedata: WwmGOqcjZWrGOTsgd46Tuuw5iqktK0bk1Mw6SXYpCBd2JySdNKt9kM1e5f033jAKhVpSk4HsQHxyUZWslApqUYntGTIOH3715xh2Bwp+GmsEnGS36PInR7uXhAVKIOzkO4uJOCcP8E4rcRWKM5Leuw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4903 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Honnappa.Nagarahalli@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT035.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39850400004)(346002)(136003)(376002)(46966005)(4326008)(81166007)(9686003)(55016002)(33656002)(110136005)(86362001)(316002)(54906003)(356005)(8676002)(47076004)(5660300002)(52536014)(8936002)(82740400003)(7696005)(2906002)(478600001)(6506007)(26826003)(81156014)(336012)(186003)(26005)(70206006)(70586007)(21314003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: a437d817-d38b-48c5-ed82-08d7e08ca348 X-Forefront-PRVS: 0373D94D15 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IsWWJyVfjH9rLuccQl7HUTPxcPKWeQN/40sBVvaBFTliL8ynuf3aabU+q5L1v6Icze3oMTTCRJHVtUu65PWKrZp/G2wCK1KKCvNrf9RW3eQIXyuKLg6MF85vIYCx653ny1u2+5gdbNEma2Ogasq/jU1tLWR5Gu3q9aZzQF8Hlr2KpBJt+eEvzQ2LPI4CX840lSvbRsaTtaepIju2mIXPuxhzrxoyFv1MWKY0aamcfVrByZzNL8TEwgZpK4dmxq8JrQS+I9Kt8Wm81UIcxV6JN/v8foJRK7lnFqLpjGI7eKVlXxha2+5MVwcZhp7obtktkJdF9dTBZQBbeMmSb/H6W5ZqjrngLBJoqHG7WEMhgLFmDSvYoCxZYq64ooSY7gv6zA5w0NIpUdwQ9QjovnvtqJ1SJPxXM6zc4EfnqO4yKcYi7OHiSDFG7Ay4CIa4dGevvebsu8p48Y5biMqxU/B22oS28V1EPSd6xnFtNC2T8BYiau5SZrrk4XgVqttqLRTx5ZQZGtpBdC0+miyYkhuP3ng+a4V6Bmi2ajynvLJZUrI= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2020 15:58:19.9814 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dfaf678c-d072-4d83-cc4d-08d7e08ca71b X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5041 Subject: Re: [dpdk-dev] [PATCH v3 3/9] ring: introduce RTS ring mode 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" > Subject: RE: [PATCH v3 3/9] ring: introduce RTS ring mode >=20 > > > > > > > > > > +#ifdef ALLOW_EXPERIMENTAL_API > > > > > +#include > > > > > +#endif > > > > > + > > > > > /** > > > > > * Enqueue several objects on a ring. > > > > > * > > > > > @@ -484,8 +520,21 @@ static __rte_always_inline unsigned int > > > > > rte_ring_enqueue_bulk(struct rte_ring *r, void * const *obj_table= , > > > > > unsigned int n, unsigned int *free_space) { > > > > > - return __rte_ring_do_enqueue(r, obj_table, n, > > > > > RTE_RING_QUEUE_FIXED, > > > > > - r->prod.sync_type, free_space); > > > > > + switch (r->prod.sync_type) { > > > > > + case RTE_RING_SYNC_MT: > > > > > + return rte_ring_mp_enqueue_bulk(r, obj_table, n, > free_space); > > > > > + case RTE_RING_SYNC_ST: > > > > > + return rte_ring_sp_enqueue_bulk(r, obj_table, n, > free_space); > > > > Have you validated if these affect the performance for the existing= APIs? > > > > > > I run ring_pmd_perf_autotest > > > (AFAIK, that's the only one of our perf tests that calls > > > rte_ring_enqueue/dequeue), and didn't see any real difference in > > > perf numbers. > > > > > > > I am also wondering why should we support these new modes in the > > > > legacy > > > APIs? > > > > > > Majority of DPDK users still do use legacy API, and I am not sure > > > all of them will be happy to switch to _elem_ one manually. > > > Plus I can't see how we can justify that after let say: > > > rte_ring_init(ring, ..., RING_F_MP_HTS_ENQ | RING_F_MC_HTS_DEQ); > > > returns with success valid call to rte_ring_enqueue(ring,...) should = fail. > > Agree, I think the only way right now is through documentation. > > > > > > > > > I think users should move to use rte_ring_xxx_elem APIs. If users > > > > want to > > > use RTS/HTS it will be a good time for them to move to new APIs. > > > > > > If they use rte_ring_enqueue/dequeue all they have to do - just > > > change flags in ring_create/ring_init call. > > > With what you suggest - they have to change every > > > rte_ring_enqueue/dequeue to rte_ring_elem_enqueue/dequeue. > > > That's much bigger code churn. > > But these are just 1 to 1 mapped. I would think, there are not a whole= lot of > them in the application code, may be ~10 lines? >=20 > I suppose it depends a lot on particular user app. > My preference not to force users to do extra changes in their code. > If we can add new functionality while keeping existing API, why not to do= it? > Less disturbance for users seems a good thing to me. >=20 > > I think the bigger factor for the user here is the algorithm changes > > in rte_ring library. Bigger effort for the users would be testing rathe= r than > code changes in the applications. > > > > > > > They anyway have to test their code for RTS/HTS, might as well > > > > make the > > > change to new APIs and test both. > > > > It will be less code to maintain for the community as well. > > > > > > That's true, right now there is a lot of duplication between _elem_ > > > and legacy code. > > > Actually the only real diff between them - actual copying of the obj= ects. > > > But I thought we are going to deal with that, just by changing one > > > day all legacy API to wrappers around _elem_ calls, i.e something lik= e: > > > > > > static __rte_always_inline unsigned int rte_ring_enqueue_bulk(struct > > > rte_ring *r, void * const *obj_table, > > > unsigned int n, unsigned int *free_space) { > > > return rte_ring_enqueue_elem_bulk(r, obj_table, sizeof(uintptr_t), > > > n, free_space); } > > > > > > That way users will switch to new API automatically, without any > > > extra effort for them, and we will be able to remove legacy code. > > > Do you have some other thoughts here how to deal with this > > > legacy/elem conversion? > > Yes, that is what I was thinking, but had not considered any addition o= f new > APIs. > > But, I am wondering if we should look at deprecation? >=20 > You mean to deprecate existing legacy API? > rte_ring_enqueue/dequeue_bulk, etc? > I don't think we need to deprecate it at all. > As long as we'll have _elem_ functions called underneath there would be = one > implementation anyway, and we can leave them forever, so users wouldn't > need to change their existing code at all. Ack (assuming that the legacy APIs will be wrappers) >=20 > > If we decide to deprecate, it would be good to avoid making the users > > of RTS/HTS do the work twice (once to make the switch to RTS/HTS and > then another to _elem_ APIs). > > > > One thing we can do is to implement the wrappers you mentioned above > for RTS/HTS now. >=20 > That's a very good point. > It will require some re-org to allow rte_ring.h to include rte_ring_elem= .h, but > I think it is doable, will try to make these changes in v4. >=20 > > I also it is worth considering to switch to these wrappers 20.05 so > > that come 20.11, we have a code base that has gone through couple of > releases' testing. >=20 > You mean wrappers for existing legacy API (MP/MC, SP/SC modes)? > It is probably too late to make such changes in 20.05, probably early 20.= 08 is > a good time for that. Yes, will target for 20.08 >=20 > > > > > > > > > > > + > > > > > +#endif /* _RTE_RING_RTS_ELEM_H_ */ > > > > > diff --git a/lib/librte_ring/rte_ring_rts_generic.h > > > > > b/lib/librte_ring/rte_ring_rts_generic.h > > > > > new file mode 100644 > > > > > index 000000000..f88460d47 > > > > > --- /dev/null > > > > > +++ b/lib/librte_ring/rte_ring_rts_generic.h > > > > I do not know the benefit to providing the generic version. Do you > > > > know > > > why this was done in the legacy APIs? > > > > > > I think at first we had generic API only, then later C11 was added. > > > As I remember, C11 one on IA was measured as a bit slower then > > > generic, so it was decided to keep both. > > > > > > > If there is no performance difference between generic and C11 > > > > versions, > > > should we just skip the generic version? > > > > The oldest compiler in CI are GCC 4.8.5 and Clang 3.4.2 and C11 > > > > built-ins > > > are supported earlier than these compiler versions. > > > > I feel the code is growing exponentially in rte_ring library and > > > > we should try > > > to cut non-value-ass code/APIs aggressively. > > > > > > I'll check is there perf difference for RTS and HTS between generic > > > and C11 versions on IA. > > > Meanwhile please have a proper look at C11 implementation, I am not > > > that familiar with C11 atomics yet. > > ok > > > > > If there would be no problems with it and no noticeable diff in > > > performance - I am ok to have for RTS/HTS modes C11 version only. >=20 > From what I see on my box, there is no much difference in terms of > performance between *generic* and *c11_mem* for RTS/HTS. > ring_stress_autotest for majority of cases shows ~1% diff, in some cases = c11 > numbers are even a bit better. > So will keep c11 version only in v4. Thanks. That will remove good amount of code.