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 8B832A0597; Thu, 9 Apr 2020 15:39:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EDA091C240; Thu, 9 Apr 2020 15:39:08 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id B4F961C23D for ; Thu, 9 Apr 2020 15:39:06 +0200 (CEST) IronPort-SDR: pYQzAIJwraHtL9Re+iCDnaggnPrgnasTtpEAfiGrK1Vj8ja29rY6qmsJwfM37XH5c2ewgk1t/J CzX3tyyZul7Q== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2020 06:39:05 -0700 IronPort-SDR: Q5xivT6kfoTeEvim6twnc9Ssa+HmvmKE1KxSKt9o72aIcQ/lTi+xyA9XHNSPGkjMNqJe2N5LDk slGGtMt0R7Ww== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,362,1580803200"; d="scan'208";a="255148405" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga006.jf.intel.com with ESMTP; 09 Apr 2020 06:39:05 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Apr 2020 06:39:05 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 9 Apr 2020 06:39:04 -0700 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 9 Apr 2020 06:39:04 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.103) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Apr 2020 06:39:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e+CXNt4tN7txARUqhTnUzwcx3sE4gRvVcqSleEJQXWZ7J5oDqKefj1DnMw7VSqXvoHyPAQxUPK+VYuquz9LaXHqQzn9rNB8sIym86gdnT8a7+F8gSTFt9kdpAE7cGO6atjbW556AfYP1u1JWazybDIGLGXiDWkTN3Ec63Sacwu2eVfPeYpVqwCeT+DADpmBvwhzfZPe1e9Ge+LuKhi3xTbHa3keAEsPHb3Lml4sEonMJhm4HpFeccGgCdwwdHSg4L5y/JTnGTPws5dzouV30uSg8wr1yDZSLMnadrsUX81UUYsr4tg7y2DSbtrATQ2Kx/mNURgK9WUq7VIidxDVUhw== 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=LsblxKP+P6xuf0Jvnqyk1Olh4UKTJB3ZqxzDiiN6BOk=; b=ELb5rQ/MfMGly0Rwn/++XEKjR0FkLr5L9K+hOgIQOOFvMDC6z9qX405L1Okx+W9wKGbiecuAkWwf1L4Z96c0Lw/dgew1LzWMPWkLae1fs9eY+Ouss/o6UJG1vFBE4mrvKXSgV96WDtQwPn3JbtTM7QJmHkClfymSBfzO61OfOoLlSbvWKCwggH8uFTiH1Y92l5hIaREcqb+0Fa13QHSMQ78Ttuigtzaa6Jcme+1hH2UKpuIdP5+Z7WKL7T2BHxz/jqcnJvNQ41dWBoV+US7ltlqh4aA06wFSQKt9Ehm62hXkif9IXj7/RMf+7dBRD6Ut5GMFHglhdozXzRPhZkM18Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LsblxKP+P6xuf0Jvnqyk1Olh4UKTJB3ZqxzDiiN6BOk=; b=fnC1G9MbVjeP8VCkFYpJRjtSFKTjFa/Naxmhla0lOFtQaOe1FkdoREdIij9aNJwXyKGYM82RXsGaSd/EBWXOtvPkButN4RKjGjXE5QAl5ujQ1QjGjgm55F/vAPjxzvevJfX+lpTIjT6V0BOLirq4z8xKexDuYEAFmwv6qtNWGKA= Received: from SN6PR11MB2558.namprd11.prod.outlook.com (2603:10b6:805:5d::19) by SN6PR11MB3311.namprd11.prod.outlook.com (2603:10b6:805:c1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.17; Thu, 9 Apr 2020 13:39:01 +0000 Received: from SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::3982:ee47:b95a:4ed4]) by SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::3982:ee47:b95a:4ed4%3]) with mapi id 15.20.2900.015; Thu, 9 Apr 2020 13:39:01 +0000 From: "Ananyev, Konstantin" To: Honnappa Nagarahalli , "dev@dpdk.org" CC: "david.marchand@redhat.com" , "jielong.zjl@antfin.com" , nd , nd Thread-Topic: [PATCH v3 2/9] ring: prepare ring to allow new sync schemes Thread-Index: AQHWCd92lqCMwtmiN0eMq3HPQu1SfqhusUmAgAIVuCA= Date: Thu, 9 Apr 2020 13:39:01 +0000 Message-ID: References: <20200402220959.29885-1-konstantin.ananyev@intel.com> <20200403174235.23308-1-konstantin.ananyev@intel.com> <20200403174235.23308-3-konstantin.ananyev@intel.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 authentication-results: spf=none (sender IP is ) smtp.mailfrom=konstantin.ananyev@intel.com; x-originating-ip: [192.198.151.161] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d29bfcf7-8d8e-4d50-129d-08d7dc8b5d43 x-ms-traffictypediagnostic: SN6PR11MB3311: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB2558.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(366004)(7696005)(6506007)(30864003)(498600001)(8936002)(33656002)(186003)(9686003)(55016002)(71200400001)(2906002)(86362001)(8676002)(81166007)(5660300002)(4326008)(64756008)(66946007)(66476007)(76116006)(54906003)(66556008)(66446008)(81156014)(26005)(52536014)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JN/iPjWpltgvBeasqcvn2vDkVj7VMkBpA2kczRFmPHpYRYUhJRmh0omQlRUUOKkXeNjd3dzMb+3gBiKsNW8eBnilqmTzbiU0SyDz7E2V/9K03DAFqUagR6fzZeD1Enp0P4A0SLG4XpXW0Hcgsf5lqj01KomaENutY5PHOh7oGRf6VBLqb4MZcv8Fjg1OvkPRkCYBR/BaWP/yXxOSzYYditwu4ngnKE+zJhosGouGpcvBkZ3rg3JN0GhFbiKYI20RZU7+A2Tl2GjY+7/xYmocyDs7NTJSx1e012yBoiaUPng47tNiPvrp1/I3r7UHYjwDAba7WDYYJOtC3OWYq5U9a2Dtpy0GGu18oK1MdytkJpc2xl1FeuwS82HQD/IzRmyk/M5eRiMP2/FNlY/PeLZuzyAEnoDr62uVAsLRPqIrRwClyvGLHfgaTBar4miUnKxn x-ms-exchange-antispam-messagedata: 94OaiU1MKLBZi48UOOMYoswFMMeOek+EPf3sh1NeR5O84DguU2Qzbg1cbiDoL83DBMP7n5YJH5ZwMQb6tkTTsMwpHzpOb8yAg4wautVy2n3RKfv6+9ABBVBspKQ+mjjNndKfzCtSybZpW/59lPoSfQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d29bfcf7-8d8e-4d50-129d-08d7dc8b5d43 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 13:39:01.8246 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BINnbMNwcQ6WsSSJL0bPlUTz134DzVTCyEG0AjqO+4p4pW7aIMwsNO7ERd8UpqS8kUaPJHoDAM1juL/a6elBH8Km7QefGNp0X1OE3KlDvxo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3311 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3 2/9] ring: prepare ring to allow new sync schemes 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: [PATCH v3 2/9] ring: prepare ring to allow new sync schemes > > > > Change from *single* to *sync_type* to allow different synchronisation > > schemes to be applied. > > Mark *single* as deprecated in comments. > > Add new functions to allow user to query ring sync types. > > Replace direct access to *single* with appopriate function call. > > > > Signed-off-by: Konstantin Ananyev > > --- > > app/test/test_pdump.c | 6 +- > > lib/librte_pdump/rte_pdump.c | 2 +- > > lib/librte_port/rte_port_ring.c | 12 ++-- > > lib/librte_ring/rte_ring.c | 6 +- > > lib/librte_ring/rte_ring.h | 113 ++++++++++++++++++++++++++------ > > lib/librte_ring/rte_ring_elem.h | 8 +-- > > 6 files changed, 108 insertions(+), 39 deletions(-) > > > > diff --git a/app/test/test_pdump.c b/app/test/test_pdump.c index > > ad183184c..6a1180bcb 100644 > > --- a/app/test/test_pdump.c > > +++ b/app/test/test_pdump.c > > @@ -57,8 +57,7 @@ run_pdump_client_tests(void) > > if (ret < 0) > > return -1; > > mp->flags =3D 0x0000; > > - ring_client =3D rte_ring_create("SR0", RING_SIZE, rte_socket_id(), > > - RING_F_SP_ENQ | RING_F_SC_DEQ); > > + ring_client =3D rte_ring_create("SR0", RING_SIZE, rte_socket_id(), 0)= ; > Are you saying to get SP and SC behavior we now have to set the flags to = 0? No. What the original cause does: creates SP/SC ring: ring_client =3D rte_ring_create("SR0", RING_SIZE, rte_socket_id(), RING_F_SP_ENQ | RING_F_SC_DEQ); Then manually makes it MP/MC by: ring_client->prod.single =3D 0; ring_client->cons.single =3D 0; Instead it should just create MP/MC ring straightway, as the patch does: ring_client =3D rte_ring_create("SR0", RING_SIZE, rte_socket_id(), 0); >Isn't that a ABI break? I don't see any. >=20 > > if (ring_client =3D=3D NULL) { > > printf("rte_ring_create SR0 failed"); > > return -1; > > @@ -71,9 +70,6 @@ run_pdump_client_tests(void) > > } > > rte_eth_dev_probing_finish(eth_dev); > > > > - ring_client->prod.single =3D 0; > > - ring_client->cons.single =3D 0; > Just wondering if users outside of DPDK have done the same. I hope not, o= therwise, we have an API break? I think no. While it is completely wrong practise, it would keep working even with these changes.=20 >=20 > > - > > printf("\n***** flags =3D RTE_PDUMP_FLAG_TX *****\n"); > > > > for (itr =3D 0; itr < NUM_ITR; itr++) { > > diff --git a/lib/librte_pdump/rte_pdump.c b/lib/librte_pdump/rte_pdump.= c > > index 8a01ac510..65364f2c5 100644 > > --- a/lib/librte_pdump/rte_pdump.c > > +++ b/lib/librte_pdump/rte_pdump.c > > @@ -380,7 +380,7 @@ pdump_validate_ring_mp(struct rte_ring *ring, struc= t > > rte_mempool *mp) > > rte_errno =3D EINVAL; > > return -1; > > } > > - if (ring->prod.single || ring->cons.single) { > > + if (rte_ring_prod_single(ring) || rte_ring_cons_single(ring)) { > > PDUMP_LOG(ERR, "ring with either SP or SC settings" > > " is not valid for pdump, should have MP and MC settings\n"); > > rte_errno =3D EINVAL; > > diff --git a/lib/librte_port/rte_port_ring.c b/lib/librte_port/rte_port= _ring.c > > index 47fcdd06a..2f6c050fa 100644 > > --- a/lib/librte_port/rte_port_ring.c > > +++ b/lib/librte_port/rte_port_ring.c > > @@ -44,8 +44,8 @@ rte_port_ring_reader_create_internal(void *params, in= t > > socket_id, > > /* Check input parameters */ > > if ((conf =3D=3D NULL) || > > (conf->ring =3D=3D NULL) || > > - (conf->ring->cons.single && is_multi) || > > - (!(conf->ring->cons.single) && !is_multi)) { > > + (rte_ring_cons_single(conf->ring) && is_multi) || > > + (!rte_ring_cons_single(conf->ring) && !is_multi)) { > > RTE_LOG(ERR, PORT, "%s: Invalid Parameters\n", __func__); > > return NULL; > > } > > @@ -171,8 +171,8 @@ rte_port_ring_writer_create_internal(void *params, > > int socket_id, > > /* Check input parameters */ > > if ((conf =3D=3D NULL) || > > (conf->ring =3D=3D NULL) || > > - (conf->ring->prod.single && is_multi) || > > - (!(conf->ring->prod.single) && !is_multi) || > > + (rte_ring_prod_single(conf->ring) && is_multi) || > > + (!rte_ring_prod_single(conf->ring) && !is_multi) || > > (conf->tx_burst_sz > RTE_PORT_IN_BURST_SIZE_MAX)) { > > RTE_LOG(ERR, PORT, "%s: Invalid Parameters\n", __func__); > > return NULL; > > @@ -440,8 +440,8 @@ rte_port_ring_writer_nodrop_create_internal(void > > *params, int socket_id, > > /* Check input parameters */ > > if ((conf =3D=3D NULL) || > > (conf->ring =3D=3D NULL) || > > - (conf->ring->prod.single && is_multi) || > > - (!(conf->ring->prod.single) && !is_multi) || > > + (rte_ring_prod_single(conf->ring) && is_multi) || > > + (!rte_ring_prod_single(conf->ring) && !is_multi) || > > (conf->tx_burst_sz > RTE_PORT_IN_BURST_SIZE_MAX)) { > > RTE_LOG(ERR, PORT, "%s: Invalid Parameters\n", __func__); > > return NULL; > > diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c in= dex > > 77e5de099..fa5733907 100644 > > --- a/lib/librte_ring/rte_ring.c > > +++ b/lib/librte_ring/rte_ring.c > > @@ -106,8 +106,10 @@ rte_ring_init(struct rte_ring *r, const char *name= , > > unsigned count, > > if (ret < 0 || ret >=3D (int)sizeof(r->name)) > > return -ENAMETOOLONG; > > r->flags =3D flags; > > - r->prod.single =3D (flags & RING_F_SP_ENQ) ? __IS_SP : __IS_MP; > > - r->cons.single =3D (flags & RING_F_SC_DEQ) ? __IS_SC : __IS_MC; > > + r->prod.sync_type =3D (flags & RING_F_SP_ENQ) ? > > + RTE_RING_SYNC_ST : RTE_RING_SYNC_MT; > > + r->cons.sync_type =3D (flags & RING_F_SC_DEQ) ? > > + RTE_RING_SYNC_ST : RTE_RING_SYNC_MT; > > > > if (flags & RING_F_EXACT_SZ) { > > r->size =3D rte_align32pow2(count + 1); diff --git > > a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h index > > 18fc5d845..d4775a063 100644 > > --- a/lib/librte_ring/rte_ring.h > > +++ b/lib/librte_ring/rte_ring.h > > @@ -61,11 +61,27 @@ enum rte_ring_queue_behavior { #define > > RTE_RING_NAMESIZE (RTE_MEMZONE_NAMESIZE - \ > > sizeof(RTE_RING_MZ_PREFIX) + 1) > > > > -/* structure to hold a pair of head/tail values and other metadata */ > > +/** prod/cons sync types */ > > +enum rte_ring_sync_type { > > + RTE_RING_SYNC_MT, /**< multi-thread safe (default mode) */ > > + RTE_RING_SYNC_ST, /**< single thread only */ > > +}; > > + > > +/** > > + * structure to hold a pair of head/tail values and other metadata. > > + * Depending on sync_type format of that structure might be different, > > + * but offset for *sync_type* and *tail* values should remain the same= . > > + */ > > struct rte_ring_headtail { > > - volatile uint32_t head; /**< Prod/consumer head. */ > > - volatile uint32_t tail; /**< Prod/consumer tail. */ > > - uint32_t single; /**< True if single prod/cons */ > > + volatile uint32_t head; /**< prod/consumer head. */ > > + volatile uint32_t tail; /**< prod/consumer tail. */ > > + RTE_STD_C11 > > + union { > > + /** sync type of prod/cons */ > > + enum rte_ring_sync_type sync_type; > > + /** deprecated - True if single prod/cons */ > > + uint32_t single; > > + }; > > }; > > > > /** > > @@ -116,11 +132,10 @@ struct rte_ring { > > #define RING_F_EXACT_SZ 0x0004 > > #define RTE_RING_SZ_MASK (0x7fffffffU) /**< Ring size mask */ > > > > -/* @internal defines for passing to the enqueue dequeue worker functio= ns > > */ -#define __IS_SP 1 -#define __IS_MP 0 -#define __IS_SC 1 -#define > > __IS_MC 0 > > +#define __IS_SP RTE_RING_SYNC_ST > > +#define __IS_MP RTE_RING_SYNC_MT > > +#define __IS_SC RTE_RING_SYNC_ST > > +#define __IS_MC RTE_RING_SYNC_MT > I think we can remove these #defines and use the new SYNC types Wouldn't that introduce an API breakage? Or we are ok here, as they are marked as internal? I think I can for sure mark them as deprecated. =20 > > > > /** > > * Calculate the memory size needed for a ring @@ -420,7 +435,7 @@ > > rte_ring_mp_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, > > - __IS_MP, free_space); > > + RTE_RING_SYNC_MT, free_space); > > } > > > > /** > > @@ -443,7 +458,7 @@ rte_ring_sp_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, > > - __IS_SP, free_space); > > + RTE_RING_SYNC_ST, free_space); > > } > > > > /** > > @@ -470,7 +485,7 @@ 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.single, free_space); > > + r->prod.sync_type, free_space); > > } > > > > /** > > @@ -554,7 +569,7 @@ rte_ring_mc_dequeue_bulk(struct rte_ring *r, void > > **obj_table, > > unsigned int n, unsigned int *available) { > > return __rte_ring_do_dequeue(r, obj_table, n, > > RTE_RING_QUEUE_FIXED, > > - __IS_MC, available); > > + RTE_RING_SYNC_MT, available); > > } > > > > /** > > @@ -578,7 +593,7 @@ rte_ring_sc_dequeue_bulk(struct rte_ring *r, void > > **obj_table, > > unsigned int n, unsigned int *available) { > > return __rte_ring_do_dequeue(r, obj_table, n, > > RTE_RING_QUEUE_FIXED, > > - __IS_SC, available); > > + RTE_RING_SYNC_ST, available); > > } > > > > /** > > @@ -605,7 +620,7 @@ rte_ring_dequeue_bulk(struct rte_ring *r, void > > **obj_table, unsigned int n, > > unsigned int *available) > > { > > return __rte_ring_do_dequeue(r, obj_table, n, > > RTE_RING_QUEUE_FIXED, > > - r->cons.single, available); > > + r->cons.sync_type, available); > > } > > > > /** > > @@ -777,6 +792,62 @@ rte_ring_get_capacity(const struct rte_ring *r) > > return r->capacity; > > } > > > > +/** > > + * Return sync type used by producer in the ring. > > + * > > + * @param r > > + * A pointer to the ring structure. > > + * @return > > + * Producer sync type value. > > + */ > > +static inline enum rte_ring_sync_type > > +rte_ring_get_prod_sync_type(const struct rte_ring *r) { > > + return r->prod.sync_type; > > +} > > + > > +/** > > + * Check is the ring for single producer. > ^^ if > > + * > > + * @param r > > + * A pointer to the ring structure. > > + * @return > > + * true if ring is SP, zero otherwise. > > + */ > > +static inline int > > +rte_ring_prod_single(const struct rte_ring *r) { > would rte_ring_is_prod_single better? Ok, can rename. >=20 > > + return (rte_ring_get_prod_sync_type(r) =3D=3D RTE_RING_SYNC_ST); } > > + > > +/** > > + * Return sync type used by consumer in the ring. > > + * > > + * @param r > > + * A pointer to the ring structure. > > + * @return > > + * Consumer sync type value. > > + */ > > +static inline enum rte_ring_sync_type > > +rte_ring_get_cons_sync_type(const struct rte_ring *r) { > > + return r->cons.sync_type; > > +} > > + > > +/** > > + * Check is the ring for single consumer. > > + * > > + * @param r > > + * A pointer to the ring structure. > > + * @return > > + * true if ring is SC, zero otherwise. > > + */ > > +static inline int > > +rte_ring_cons_single(const struct rte_ring *r) { > > + return (rte_ring_get_cons_sync_type(r) =3D=3D RTE_RING_SYNC_ST); } > > + > All these new functions are not required to be called in the data path. = They can be made non-inline. Well, all these functions are introduced to encourage people not to access ring fields sync_type/single directly but use functions instead. I don't know do people access ring.single directly at data-path or not, but assuming that they do - making these functions not-inline would=20 force them to ignore these functions and keep accessing it directly. That was my thoughts besides making them inline. I think we have the same for get_size/get_capacity().