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 inbox.dpdk.org (Postfix) with ESMTP id 5C2EBA2EDB
for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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" <konstantin.ananyev@intel.com>
To: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"paulmck@linux.ibm.com" <paulmck@linux.ibm.com>
CC: "Wang, Yipeng1" <yipeng1.wang@intel.com>, "Medvedkin, Vladimir"
<vladimir.medvedkin@intel.com>, "ruifeng.wang@arm.com"
<ruifeng.wang@arm.com>, "dharmik.thakkar@arm.com" <dharmik.thakkar@arm.com>,
"dev@dpdk.org" <dev@dpdk.org>, "nd@arm.com" <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 <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>
> -----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 <konstantin.ananyev=
@intel.com>; stephen@networkplumber.org;
> paulmck@linux.ibm.com
> Cc: Wang, Yipeng1 <yipeng1.wang@intel.com>; Medvedkin, Vladimir <vladimir=
.medvedkin@intel.com>; 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 <ruifeng.wang@arm.com>
>=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 <dharmik.thakkar@arm.com>
> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> ---
> 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