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 5C2EBA2EDB for ; Wed, 2 Oct 2019 20:42:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C716D1BF4B; Wed, 2 Oct 2019 20:42:10 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 08B921BF4A for ; Wed, 2 Oct 2019 20:42:08 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2019 11:42:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,249,1566889200"; d="scan'208";a="194959910" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga003.jf.intel.com with ESMTP; 02 Oct 2019 11:42:05 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX108.ger.corp.intel.com ([169.254.11.112]) with mapi id 14.03.0439.000; Wed, 2 Oct 2019 19:42:05 +0100 From: "Ananyev, Konstantin" To: Honnappa Nagarahalli , "stephen@networkplumber.org" , "paulmck@linux.ibm.com" CC: "Wang, Yipeng1" , "Medvedkin, Vladimir" , "ruifeng.wang@arm.com" , "dharmik.thakkar@arm.com" , "dev@dpdk.org" , "nd@arm.com" Thread-Topic: [PATCH v3 1/3] lib/ring: add peek API Thread-Index: AQHVeCGUIgBwOBQCI0OY47a7OfyurKdHoInw Date: Wed, 2 Oct 2019 18:42:04 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580191970014@irsmsx105.ger.corp.intel.com> References: <20190906094534.36060-1-ruifeng.wang@arm.com> <20191001062917.35578-1-honnappa.nagarahalli@arm.com> <20191001062917.35578-2-honnappa.nagarahalli@arm.com> In-Reply-To: <20191001062917.35578-2-honnappa.nagarahalli@arm.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2U1YWIyNDktZmY3Ny00YzdhLWIzYTQtZDY5NTY1ZGZhMTA5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSDd5b0ljd0FYVmhFenFQYVwvaitLZnBzdFN4SjVoQ2kxeTlzNTA1dWhINVc0TTJuMFBkT1MwejA5Y2R5RmM2UkcifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 1/3] lib/ring: add peek API 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" > -----Original Message----- > From: Honnappa Nagarahalli [mailto:honnappa.nagarahalli@arm.com] > Sent: Tuesday, October 1, 2019 7:29 AM > To: honnappa.nagarahalli@arm.com; Ananyev, Konstantin ; stephen@networkplumber.org; > paulmck@linux.ibm.com > Cc: Wang, Yipeng1 ; Medvedkin, Vladimir ; ruifeng.wang@arm.com; > dharmik.thakkar@arm.com; dev@dpdk.org; nd@arm.com > Subject: [PATCH v3 1/3] lib/ring: add peek API >=20 > From: Ruifeng Wang >=20 > The peek API allows fetching the next available object in the ring > without dequeuing it. This helps in scenarios where dequeuing of > objects depend on their value. >=20 > Signed-off-by: Dharmik Thakkar > Signed-off-by: Ruifeng Wang > Reviewed-by: Honnappa Nagarahalli > Reviewed-by: Gavin Hu > --- > lib/librte_ring/rte_ring.h | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) >=20 > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h > index 2a9f768a1..d3d0d5e18 100644 > --- a/lib/librte_ring/rte_ring.h > +++ b/lib/librte_ring/rte_ring.h > @@ -953,6 +953,36 @@ rte_ring_dequeue_burst(struct rte_ring *r, void **ob= j_table, > r->cons.single, available); > } >=20 > +/** > + * Peek one object from a ring. > + * > + * The peek API allows fetching the next available object in the ring > + * without dequeuing it. This API is not multi-thread safe with respect > + * to other consumer threads. > + * > + * @param r > + * A pointer to the ring structure. > + * @param obj_p > + * A pointer to a void * pointer (object) that will be filled. > + * @return > + * - 0: Success, object available > + * - -ENOENT: Not enough entries in the ring. > + */ > +__rte_experimental > +static __rte_always_inline int > +rte_ring_peek(struct rte_ring *r, void **obj_p) As it is not MT safe, then I think we need _sc_ in the name, to follow other rte_ring functions naming conventions (rte_ring_sc_peek() or so). As a better alternative what do you think about introducing=20 a serialized versions of DPDK rte_ring dequeue functions? Something like that: /* same as original ring dequeue, but: * 1) move cons.head only if cons.head =3D=3D const.tail * 2) don't update cons.tail */ unsigned int rte_ring_serial_dequeue_bulk(struct rte_ring *r, void **obj_table, unsigned= int n, unsigned int *available); /* sets both cons.head and cons.tail to cons.head + num */ void rte_ring_serial_dequeue_finish(struct rte_ring *r, uint32_t num); /* resets cons.head to const.tail value */ void rte_ring_serial_dequeue_abort(struct rte_ring *r); Then your dq_reclaim cycle function will look like that: const uint32_t nb_elt =3D dq->elt_size/8 + 1; uint32_t avl, n; uintptr_t elt[nb_elt]; ... do { /* read next elem from the queue */ n =3D rte_ring_serial_dequeue_bulk(dq->r, elt, nb_elt, &avl); if (n =3D=3D 0) break;=20 /* wrong period, keep elem in the queue */ =20 if (rte_rcu_qsbr_check(dr->v, elt[0]) !=3D 1) { rte_ring_serial_dequeue_abort(dq->r); break; } /* can reclaim, remove elem from the queue */ rte_ring_serial_dequeue_finish(dr->q, nb_elt); /*call reclaim function */ dr->f(dr->p, elt); } while (avl >=3D nb_elt); That way, I think even rte_rcu_qsbr_dq_reclaim() can be MT safe. As long as actual reclamation callback itself is MT safe of course. > +{ > + uint32_t prod_tail =3D r->prod.tail; > + uint32_t cons_head =3D r->cons.head; > + uint32_t count =3D (prod_tail - cons_head) & r->mask; > + unsigned int n =3D 1; > + if (count) { > + DEQUEUE_PTRS(r, &r[1], cons_head, obj_p, n, void *); > + return 0; > + } > + return -ENOENT; > +} > + > #ifdef __cplusplus > } > #endif > -- > 2.17.1