[dpdk-dev] [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by the drivers

Jerin Jacob jerinjacobk at gmail.com
Sat Mar 27 14:15:06 CET 2021


On Thu, Mar 25, 2021 at 1:51 PM Matan Azrad <matan at nvidia.com> wrote:
>
> Hi Cristian
>
> From: Dumitrescu, Cristian
> > Hi Li and Matan,
> >
> > > -----Original Message-----
> > > From: Li Zhang <lizh at nvidia.com>
> > > Sent: Thursday, March 18, 2021 8:58 AM
> > > To: dekelp at nvidia.com; orika at nvidia.com; viacheslavo at nvidia.com;
> > > matan at nvidia.com; shahafs at nvidia.com; lironh at marvell.com; Singh,
> > > Jasvinder <jasvinder.singh at intel.com>; Thomas Monjalon
> > > <thomas at monjalon.net>; Yigit, Ferruh <ferruh.yigit at intel.com>; Andrew
> > > Rybchenko <andrew.rybchenko at oktetlabs.ru>; Dumitrescu, Cristian
> > > <cristian.dumitrescu at intel.com>
> > > Cc: dev at dpdk.org; rasland at nvidia.com; roniba at nvidia.com
> > > Subject: [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by
> > > the drivers
> > >

>
> Yes, it changes all API, but very small part in each, will be very easy to align all the current dpdk components to use this concept.
>
> > If you guys insist with this proposal, I would like to get more opinions from
> > other vendors and contributors from within our DPDK community.
>
>
> Yes, more opinions are very welcomed.

This point was discussed to the core in the initial meter RFC.

IMO, IDs helps in managing meter objects more clean way with lookup
cost. especially, If a non DPDK application, managing the meter ID
via some sort of IPC.

Considering existing APIs and drivers are implemented with ID scheme,
I think, it would be better to give some performance data for
changing the scheme.

I was under impression that, Typical number of MAX meter HW objects
could be around 16k something and the number of meter objects
created and destroyed per second will be very low. (In the order to
16k ops per second).

Could you share the practical number of meter HW objects in MLX SoCs
and the number of operations are you are envisioning?

>
> Thanks


More information about the dev mailing list