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

[Andrew Rybchenko]

Hi Ori,

On 5/19/22 11:41, Ori Kam wrote:
> Hi Andrew,
> 
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko at 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 at 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).

Good point. I've missed such usage of an 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.
>>>
>