On Wed, May 18, 2022 12:51 Andrew Rybchenko <andrew.rybche...@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. > 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.
