RE: [RFC] ethdev: datapath-focused meter actions, continue

[Ori Kam <orika@nvidia.com>]

Hi Andrew,

> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Thursday, May 19, 2022 9:45 AM
> Subject: Re: [RFC] ethdev: datapath-focused meter actions, continue
> 
> On 5/19/22 05:17, Alexander Kozyrev wrote:
> > On Wed, May 18, 2022 12:51 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>:
> >> 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.
> >
> > Thank you for taking some time and reviewing this RFC.
> >
> >> 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.
> >
> > Yes, and what I propose is the flexible version of Meters where both
> > profiles and policies can be used separately. But flexibility comes with
> > a price of taking care of both of them separately as well, of course.
> >
> >> 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.
> >
> > We don't need to assign a TAG. I used the TAG as example on how we can
> > combine color matching with any other item matching.  Model stays the same.
> > You still do color marking with a meter and find actions based on a color.
> 
> I general yes, but I've tried to highlight the case when the
> same meter should be applied to different flows. If so, you
> need a way to combine. Old way allows to do it in a single step - just
> specify meter ID. New way needs extra rule, for example,
> using TAG or MARK.
> 
If you want the same meter to be used by different rules, you can just
use the action handle (indirect action).
The tag is used in order to demux the rules after the color matching.

Example for such use case:
You have a share meter for a user, The user has number of connections,
(Youtube, web, game)
So the first thing the application does it checks the user meter
Group 0:
Match (user youtube 5 tuple) actions shared_meter set_tag(youtube) jump to group 1
Match (user web 5 tuple) actions shared_meter set_tag(web) jump to group 1
Match (user game 5 tuple) actions shared_meter set_tag(game) jump to group 1

Group 1:  (this is what we currently call profile,)
Match color == green jump group 2
Match color == red drop

Group 2:
Match tag == youtube actions youtube related actions
Match tag == web actions web related actions
Match tag == game actions game related actions

Using the new API you can combine Group 1 and 2 (group 2 will no be needed anymore)
Group 1':
Match tag == youtube and color == green  actions youtube related actions
Match tag == weband color == green actions web related actions
Match tag == game and color == green actions game related actions
Match color == red drop

As you can see, to implement the logic in current API we must use 3 groups while,
using the suggested APi we can just use 2 groups.


> >
> >> 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.
> >
> > Yes, old model can be expressed via new API and new model can be
> > simulated with the old API. Efficiency and performance is the key.
> >
> >> Indirect actions or action templates could help to do meter profile job
> >> - define profile in single place.
> >
> > True, meter color marking may be used for meter sharing, for example.
> >
> >> 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.
> >
> > Thank you.
> >
> >> May be I'm missing something since I'm not expert in QoS and have no
> >> hands-on experience with meters in DPDK.
> >>
> >> Andrew.
> >