From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Alexander Kozyrev <akozyrev@nvidia.com>,
Ori Kam <orika@nvidia.com>, Jerin Jacob <jerinj@marvell.com>,
Cristian Dumitrescu <cristian.dumitrescu@intel.com>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
"Vipin.Varghese@amd.com" <Vipin.Varghese@amd.com>,
Ajit Khaparde <ajit.khaparde@broadcom.com>,
Ferruh Yigit <ferruh.yigit@xilinx.com>
Cc: Ray Kinsella <mdr@ashroe.eu>,
Sunil Kumar Kori <skori@marvell.com>,
Ivan Malov <ivan.malov@oktetlabs.ru>,
"Awal, Mohammad Abdul" <mohammad.abdul.awal@intel.com>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
Konstantin Ananyev <konstantin.ananyev@intel.com>,
"Singh, Jasvinder" <jasvinder.singh@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [RFC] ethdev: datapath-focused meter actions, continue
Date: Wed, 18 May 2022 19:51:26 +0300 [thread overview]
Message-ID: <f5ef3b8a-54c1-a7d6-5ca5-a7eb4b0fe010@oktetlabs.ru> (raw)
In-Reply-To: <DM5PR12MB2405352A0EB057E3E5B7D0E3AFCF9@DM5PR12MB2405.namprd12.prod.outlook.com>
Hi all,
I'm sorry, I'm not sure that I can take part in tomorrow meeting, so,
I'd like to drop my thoughts on the topic via E-mail.
Existing "meter" object which pulls profile and policy together allows
do apply metering in one flow-based lookup for different flows.
I.e. we can route absolutely different flows to one meter object to
share metering counters. When we know meter ID for a flow, everything
becomes simple - just get corresponding metering counters, apply it and
do actions based on color. Yes, it is not flexible, but very simple. As
I understand the configuration model enforces to define actions for all
colors.
A new model, if I'm not mistaken, will require three flow-based lookups:
1. To assign a TAG based on flow fields (to handle different flows in
one meter)
2. To do metering for packets with a TAG
3. To find actions based on color
Of course, (2) and (3) are done in existing model with meter ID, but
here it is a generic flow-based lookups with extra matching criteria.
Yes, it is true that it gives extra flexibility, but everything has its
price.
Theoretically old model could be expressed using new one (and,
therefore, supported on old HW), but it is a bit tricky and raises many
questions on how to handle it correctly in all cases. E.g. if a TAG is
the only pattern in non-zero table and used for meter+jump actions only,
it could be associated with meter ID.
Above jump table specified after meter action could be associated with a
policy ID. If action for a color is not specified in a table, it should
be drop by default.
Indirect actions or action templates could help to do meter profile job
- define profile in single place.
To sum up, since some HW could support the flexibility provided by
suggested flow API items/actions. I see no reason to block it. Solution
looks good from flow API design point of view.
May be I'm missing something since I'm not expert in QoS and have no
hands-on experience with meters in DPDK.
Andrew.
next prev parent reply other threads:[~2022-05-18 16:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 18:15 Alexander Kozyrev
2022-05-18 16:51 ` Andrew Rybchenko [this message]
2022-05-19 2:17 ` Alexander Kozyrev
2022-05-19 6:44 ` Andrew Rybchenko
2022-05-19 8:41 ` Ori Kam
2022-05-19 9:42 ` Andrew Rybchenko
2022-05-19 13:55 ` Jerin Jacob
2022-05-19 14:34 ` Dumitrescu, Cristian
[not found] <DM8PR11MB56700A79B2A579AD7A743A3DEBCA9@DM8PR11MB5670.namprd11.prod.outlook.com>
2022-05-19 17:34 ` Dumitrescu, Cristian
2022-05-22 2:49 ` Alexander Kozyrev
2022-05-22 5:00 ` Ajit Khaparde
2022-05-22 8:03 ` Ori Kam
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=f5ef3b8a-54c1-a7d6-5ca5-a7eb4b0fe010@oktetlabs.ru \
--to=andrew.rybchenko@oktetlabs.ru \
--cc=Vipin.Varghese@amd.com \
--cc=ajit.khaparde@broadcom.com \
--cc=akozyrev@nvidia.com \
--cc=bruce.richardson@intel.com \
--cc=cristian.dumitrescu@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@xilinx.com \
--cc=ivan.malov@oktetlabs.ru \
--cc=jasvinder.singh@intel.com \
--cc=jerinj@marvell.com \
--cc=konstantin.ananyev@intel.com \
--cc=mdr@ashroe.eu \
--cc=mohammad.abdul.awal@intel.com \
--cc=orika@nvidia.com \
--cc=qi.z.zhang@intel.com \
--cc=skori@marvell.com \
--cc=thomas@monjalon.net \
/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).