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

[Jerin Jacob <jerinjacobk@gmail.com>]

On Mon, May 16, 2022 at 11:45 PM Alexander Kozyrev <akozyrev@nvidia.com> wrote:
>
> Agenda: continue discussion about proposed improvements to Flow API in regards to Meter handling (slides attached).



I think, primary difference between the old and new methods are where
the meter HW objects are available.
In the old method, it is more in NIC HW and in the new method it is
more in flow processor HW.

Also, I think, new method is more aligned with p4
(https://p4.org/p4-spec/docs/PSA.html#sec-meter) where things are done
using a flow processor kind of HW.

Emulating each approach is costly. So I don't see any harm in keeping
a new method(without removing the old method) for a specific set of
HWs that has such features.

But looking at the API specification it is not easy to understand how
to enable this example use case as it is complicated.
Could you share pseudo code from application perspective for the
following use case.

1) Meter0 has profile of srtcm_rfc2697 of RFC 2697 with packet based metering
2) Meter1 has profile of trtcm_rfc2698 of RFC 2698 with byte based metering
3) Meter2 has profile of trtcm_rfc4115 of  RFC 4115 with packet based metering
4)If VLAN ID is X then do Meter1 ,
- if output color is RED then drop the packet
- if output color is YELLOW then do Meter0
--If the out color for Meter 0 is not RED then forward to Queue 0 else
drop the packet.
5)If VLAN ID is Y then do Meter2 and define the input color from VLAN
PCP field(000-means Green, Remaining means Yellow)
--If the output color is Green and packet is IPV4 and forward the packet Queue 0
--If the output color is Green and packet is IPV6 and forward the packet Queue 1
- If the output color is not Green then drop the packet.

Listed above use case to just test API specification to be sure that
we have not missed anything so that new approach we can address all
metering requirements.

Thanks,
Jerin.