> -----Original Message----- > From: Jerin Jacob <[email protected]> > Sent: Thursday, May 19, 2022 2:56 PM > To: Alexander Kozyrev <[email protected]> > Cc: Ori Kam <[email protected]>; Jerin Jacob <[email protected]>; > Dumitrescu, Cristian <[email protected]>; NBU-Contact-Thomas > Monjalon (EXTERNAL) <[email protected]>; Andrew Rybchenko > <[email protected]>; [email protected]; Ajit Khaparde > <[email protected]>; Ferruh Yigit <[email protected]>; Ray > Kinsella <[email protected]>; Sunil Kumar Kori <[email protected]>; Ivan Malov > <[email protected]>; Awal, Mohammad Abdul > <[email protected]>; Zhang, Qi Z <[email protected]>; > Richardson, Bruce <[email protected]>; Konstantin Ananyev > <[email protected]>; Singh, Jasvinder > <[email protected]>; [email protected] > Subject: Re: [RFC] ethdev: datapath-focused meter actions, continue > > On Mon, May 16, 2022 at 11:45 PM Alexander Kozyrev <[email protected]> > 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.
