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

[Jerin Jacob]

On Tue, Mar 30, 2021 at 1:40 AM Matan Azrad <matan at nvidia.com> wrote:
>
> Hi Jerin


Hi Matan

>
> Thanks for the review.
> PSB
>
> From: Jerin Jacob
> > 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.
>
> Although it is not the main topic here I ask:
> What is the difference between pointer to ID for the cost topic? Both are unique IDs actually....

Once is defined by app and another one by implemention.


>
> > 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?
>
> We are talking about 4M HW meters in the next version of mlx5 driver.
> The rate of flows(with meter action) creation\deletion can arrive to 200K-300K per second and we are working hard to improve it more.
>
> Can you please give also your opinion about the owner of the ID\pointer?

Just to clarify, When you have 4M HW meters, At least, you have will
4M registers or 4M context memory kind
of an interface between HW<->SW set/get meter-specific objects. Or Is
it some kind of emulation over SW?

If it 4M HW meters then ID scheme makes sense.


> The main goal of this patch is to move the owner from the application to the driver....
>
>
>
>
>
> > >
> > > Thanks