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

[Andrew Rybchenko]

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.

> 
>> 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.
>