From: Matan Azrad <matan@nvidia.com>
To: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
Li Zhang <lizh@nvidia.com>, Dekel Peled <dekelp@nvidia.com>,
Ori Kam <orika@nvidia.com>,
Slava Ovsiienko <viacheslavo@nvidia.com>,
Shahaf Shuler <shahafs@nvidia.com>,
"lironh@marvell.com" <lironh@marvell.com>,
"Singh, Jasvinder" <jasvinder.singh@intel.com>,
NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Jerin Jacob <jerinjacobk@gmail.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Doherty, Declan" <declan.doherty@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Raslan Darawsheh <rasland@nvidia.com>,
Roni Bar Yanai <roniba@nvidia.com>
Subject: Re: [dpdk-dev] [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by the drivers
Date: Mon, 29 Mar 2021 19:56:20 +0000 [thread overview]
Message-ID: <BL0PR12MB248375787C1C871961F3C5F0DF7E9@BL0PR12MB2483.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CACZ4nhvRgJdwg588uEZzdVRp40uupMp_nJPxaehr6PVpbC7TXQ@mail.gmail.com>
Hi Ajit
Looks like you agree with this RFC to move meter objects to be managed by PMD pointers.
Thanks for the review!
From: Ajit Khaparde
> On Thu, Mar 25, 2021 at 1:21 AM Matan Azrad <matan@nvidia.com> wrote:
> >
> > Hi Cristian
> >
> > From: Dumitrescu, Cristian
> > > Hi Li and Matan,
> > >
> > > > -----Original Message-----
> > > > From: Li Zhang <lizh@nvidia.com>
> > > > Sent: Thursday, March 18, 2021 8:58 AM
> > > > To: dekelp@nvidia.com; orika@nvidia.com; viacheslavo@nvidia.com;
> > > > matan@nvidia.com; shahafs@nvidia.com; lironh@marvell.com; Singh,
> > > > Jasvinder <jasvinder.singh@intel.com>; Thomas Monjalon
> > > > <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; Andrew
> > > > Rybchenko <andrew.rybchenko@oktetlabs.ru>; Dumitrescu, Cristian
> > > > <cristian.dumitrescu@intel.com>
> > > > Cc: dev@dpdk.org; rasland@nvidia.com; roniba@nvidia.com
> > > > Subject: [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by
> > > > the drivers
> > > >
> > > > Currently, all the meter objects are managed by the user IDs:
> > > > meter, profile and policy.
> > > > Hence, each PMD should manage data-structure in order to map each API
> > > > ID to the private PMD management structure.
> > > >
> > > > From the application side, it has all the picture how meter is going
> > > > to be assigned to flows and can easily use direct mapping even when
> > > > the meter handler is provided by the PMDs.
> > > >
> > > > Also, this is the approach of the rte_flow API handles:
> > > > the flow handle and the shared action handle is provided by the PMDs.
> > > >
> > > > Use drivers handlers in order to manage all the meter API objects.
> > > >
> > >
> > > This seems to be take 2 of the discussion that we already had in this thread:
> > >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dp
> > > dk.org%2Farchives%2Fdev%2F2021-
> > >
> March%2F200710.html&data=04%7C01%7Cmatan%40nvidia.com%7Cab0
> > >
> e3cc77b9e4101344e08d8ee434bbe%7C43083d15727340c1b7db39efd9ccc17a%
> > >
> 7C0%7C0%7C637521320105450617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > >
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> > >
> amp;sdata=94bFRICfGEzk5s53MRUvFMQe5ZlhP2Tmnu82hwUytc4%3D&re
> > > served=0, so apologies for mostly summarizing my previous feedback here.
> > >
> > > I am against this proposal because:
> > > 1. We already discussed this topic of user-provided handles vs. driver-
> provided
> > > handles at length on this exact email list back in 2017, when we first
> introduced
> > > this API, and I don't see any real reason to revisit the decision we took then.
> >
> > Why not?
> > There is more experiences\usages now.
> > New drivers added the support and also now scalability is growing and
> growing....
> >
> >
> > > 2. For me, it is more natural and it also helps the application to simplify its
> data
> > > structures if the user provides its own IDs rather than the user having to
> deal
> > > with the IDs provided by the driver.
> >
> > Generally I don't think other flow DPDK APIs align with your feelings here, see
> rte_flow object and rte_flow_shared_action.
> >
> > Specifically for meter:
> > - here, meter is HW\driver offload where performance\rate either for
> meter creation\deletion or for the actual data-path is very important especially
> when we talk on very big numbers, so "natural" has less importance here.
> > We need to think on the global solution for application ->API->driver. in
> meter feature, the user has the ability to manage the IDs better than the PMDs
> for the most of the use-cases:
> > 1. meter per flow: just save the driver handle in the app flow
> context.
> > 2. meter per VM\USER flows\rte_flow group\any other context
> grouped multiple flows: just save the driver handle in the app context.
> > If PMD need to map the IDs, it is more complex for sure, requires more
> memory and more lookup time.
> >
> > - I'm not sure it is natural for all the use-cases, sometimes generating
> unique ID may complex the app.
> >
> >
> > > 3. It is much easier and portable to pass numeric and string-based IDs
> around
> > > (e.g. between processes) as opposed to pointer-based IDs, as pointers are
> only
> > > valid in one address space and not in others. There are several DPDK APIs
> that
> > > moved away from pointer handles to string IDs.
> Pardon my ignorance..
> But which DPDK APIs moved to string IDs from pointer handles?
>
> >
> > Yes, I agree here generally.
> > But again, since meter is used only by rte_flow, it is better to align the same
> handle mechanism.
> I don't want to say - do this because rte_flow uses a pointer.
> I don't have a strong opinion for one over the other. In the end the
> logic can be adapted one way or the other.
> But having implemented rte_flow support in the PMD, I think it is a
> good idea to avoid the duplication of meter_id to pointer based handle
> conversion and bookkeeping logic in the application and the PMD.
>
> >
> > > 4. The mapping of user IDs to internal pointers within the driver is IMO not
> a
> > > big issue in terms of memory footprint or API call rate. Matan also
> confirmed
> > > this in the above thread when saying tis is not about either driver memory
> > > footprint or API call speed, as this mapping is easy to optimize.
> >
> > Yes, it is not very big deal, but still costs more than the new suggestion,
> especially in big scale.
> >
> > > And last but not least, this change obviously propagates in every API
> function,
> > > so it would result in big churn in API, all drivers and all apps (including
> testpmd,
> > > etc) implementing it (for IMO no real benefit). Yes, this API is experimental
> and
> > > therefore we can operate changes in it, but I'd rather see incremental and
> > > converging improvements rather than this.
> >
> > 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.
> >
> > Thanks
next prev parent reply other threads:[~2021-03-29 19:56 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-18 8:58 [dpdk-dev] [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API Li Zhang
2021-03-18 8:58 ` [dpdk-dev] [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by the drivers Li Zhang
2021-03-23 21:33 ` Dumitrescu, Cristian
2021-03-25 8:21 ` Matan Azrad
2021-03-25 23:16 ` Ajit Khaparde
2021-03-29 19:56 ` Matan Azrad [this message]
2021-03-27 13:15 ` Jerin Jacob
2021-03-29 20:10 ` Matan Azrad
2021-03-31 10:22 ` Jerin Jacob
2021-03-23 21:02 ` [dpdk-dev] [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API Dumitrescu, Cristian
2021-03-25 6:56 ` Matan Azrad
2021-03-29 9:23 ` Ori Kam
2021-03-29 16:24 ` Dumitrescu, Cristian
2021-04-01 13:13 ` Ori Kam
2021-04-01 13:35 ` Dumitrescu, Cristian
2021-04-01 14:22 ` Ori Kam
2021-03-29 16:08 ` Dumitrescu, Cristian
2021-03-29 20:43 ` Matan Azrad
2021-03-31 15:46 ` Dumitrescu, Cristian
2021-04-04 13:48 ` Matan Azrad
2021-03-29 10:38 ` Jerin Jacob
2021-03-29 20:31 ` Matan Azrad
2021-03-31 10:50 ` Jerin Jacob
2021-04-13 0:14 ` [dpdk-dev] [PATCH v3 0/2] Support " Li Zhang
2021-04-13 0:14 ` [dpdk-dev] [PATCH v3 1/2] ethdev: add pre-defined " Li Zhang
2021-04-13 14:19 ` Dumitrescu, Cristian
2021-04-14 3:23 ` Li Zhang
2021-04-13 14:59 ` Dumitrescu, Cristian
2021-04-14 4:55 ` Li Zhang
2021-04-14 8:02 ` Thomas Monjalon
2021-04-14 8:31 ` Matan Azrad
2021-04-14 8:47 ` Asaf Penso
2021-04-14 8:59 ` Li Zhang
2021-04-14 9:04 ` Thomas Monjalon
2021-04-14 14:00 ` Dumitrescu, Cristian
2021-04-14 16:21 ` Li Zhang
2021-04-13 16:25 ` Kinsella, Ray
2021-04-13 0:14 ` [dpdk-dev] [PATCH v3 2/2] app/testpmd: support policy actions per color Li Zhang
2021-04-14 3:12 ` [dpdk-dev] [PATCH v4 0/2] Support meter policy API Li Zhang
2021-04-14 3:12 ` [dpdk-dev] [PATCH v4 1/2] ethdev: add pre-defined " Li Zhang
2021-04-14 3:12 ` [dpdk-dev] [PATCH v4 2/2] app/testpmd: support policy actions per color Li Zhang
2021-04-14 6:32 ` [dpdk-dev] [PATCH v5 0/2] Support meter policy API Li Zhang
2021-04-14 6:32 ` [dpdk-dev] [PATCH v5 1/2] ethdev: add pre-defined " Li Zhang
2021-04-14 6:32 ` [dpdk-dev] [PATCH v5 2/2] app/testpmd: support policy actions per color Li Zhang
2021-04-14 8:57 ` [dpdk-dev] [PATCH v6 0/2] Support meter policy API Li Zhang
2021-04-14 8:57 ` [dpdk-dev] [PATCH v6 1/2] ethdev: add pre-defined " Li Zhang
2021-04-14 16:16 ` Dumitrescu, Cristian
2021-04-15 1:59 ` Li Zhang
2021-04-14 22:21 ` Singh, Jasvinder
2021-04-15 2:00 ` Li Zhang
2021-04-14 8:58 ` [dpdk-dev] [PATCH v6 2/2] app/testpmd: support policy actions per color Li Zhang
2021-04-15 4:54 ` [dpdk-dev] [PATCH v7 0/2] Support meter policy API Li Zhang
2021-04-15 4:54 ` [dpdk-dev] [PATCH v7 1/2] ethdev: add pre-defined " Li Zhang
2021-04-15 4:54 ` [dpdk-dev] [PATCH v7 2/2] app/testpmd: support policy actions per color Li Zhang
2021-04-15 9:20 ` [dpdk-dev] [PATCH v8 0/2] Support meter policy API Li Zhang
2021-04-15 9:20 ` [dpdk-dev] [PATCH v8 1/2] ethdev: add pre-defined " Li Zhang
2021-04-15 15:13 ` Ori Kam
2021-04-19 12:34 ` Singh, Jasvinder
2021-04-19 16:13 ` Jiawei(Jonny) Wang
2021-04-15 9:20 ` [dpdk-dev] [PATCH v8 2/2] app/testpmd: support policy actions per color Li Zhang
2021-04-19 16:08 ` [dpdk-dev] [PATCH v9 0/2] Support meter policy API Jiawei Wang
2021-04-19 16:08 ` [dpdk-dev] [PATCH v9 1/2] ethdev: add pre-defined " Jiawei Wang
2021-04-20 11:18 ` Dumitrescu, Cristian
2021-04-20 12:55 ` Asaf Penso
2021-04-20 21:01 ` Dumitrescu, Cristian
2021-04-19 16:08 ` [dpdk-dev] [PATCH v9 2/2] app/testpmd: support policy actions per color Jiawei Wang
2021-04-20 11:36 ` [dpdk-dev] [PATCH v9 0/2] Support meter policy API Ferruh Yigit
2021-04-20 14:08 ` Jiawei(Jonny) Wang
2021-04-20 14:04 ` [dpdk-dev] [PATCH v10 " Jiawei Wang
2021-04-20 14:04 ` [dpdk-dev] [PATCH v10 1/2] ethdev: add pre-defined " Jiawei Wang
2021-04-20 17:12 ` Ajit Khaparde
2021-04-21 19:43 ` Thomas Monjalon
2021-04-22 1:29 ` Li Zhang
2021-04-20 14:04 ` [dpdk-dev] [PATCH v10 2/2] app/testpmd: support policy actions per color Jiawei Wang
2021-04-20 17:14 ` Ajit Khaparde
2021-04-21 10:23 ` [dpdk-dev] [PATCH v10 0/2] Support meter policy API Ferruh Yigit
2021-04-20 17:56 ` [dpdk-dev] [PATCH 1/2] [RFC]: ethdev: add pre-defined " Stephen Hemminger
2021-04-21 2:49 ` Li Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BL0PR12MB248375787C1C871961F3C5F0DF7E9@BL0PR12MB2483.namprd12.prod.outlook.com \
--to=matan@nvidia.com \
--cc=ajit.khaparde@broadcom.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=cristian.dumitrescu@intel.com \
--cc=declan.doherty@intel.com \
--cc=dekelp@nvidia.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jasvinder.singh@intel.com \
--cc=jerinjacobk@gmail.com \
--cc=lironh@marvell.com \
--cc=lizh@nvidia.com \
--cc=orika@nvidia.com \
--cc=rasland@nvidia.com \
--cc=roniba@nvidia.com \
--cc=shahafs@nvidia.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).