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

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, May 19, 2022 2:56 PM
> To: Alexander Kozyrev <akozyrev@nvidia.com>
> Cc: Ori Kam <orika@nvidia.com>; Jerin Jacob <jerinj@marvell.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; NBU-Contact-Thomas
> Monjalon (EXTERNAL) <thomas@monjalon.net>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Vipin.Varghese@amd.com; Ajit Khaparde
> <ajit.khaparde@broadcom.com>; Ferruh Yigit <ferruh.yigit@xilinx.com>; Ray
> Kinsella <mdr@ashroe.eu>; Sunil Kumar Kori <skori@marvell.com>; Ivan Malov
> <ivan.malov@oktetlabs.ru>; Awal, Mohammad Abdul
> <mohammad.abdul.awal@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> Richardson, Bruce <bruce.richardson@intel.com>; Konstantin Ananyev
> <konstantin.ananyev@intel.com>; Singh, Jasvinder
> <jasvinder.singh@intel.com>; dev@dpdk.org
> Subject: Re: [RFC] ethdev: datapath-focused meter actions, continue
> 
> 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.
> 

Not really. In P4 PSA, the array of meters is defined upfront (initialization). Yes, the meters are configured at run-time by the control plane, with a default output color of green specified by the spec for an unconfigured meter.


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

Yes, but we should try to avoid duplicating APIs for the same functionality, if possible.

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

I have the same problem, it is difficult for me to visualize what happens when by whom, a simple pseudocode example would help a lot.

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