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

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

Hi folks,

Here are a few takeaways of mine, with a few actions for Alex and Ori:

1. Problem with pre-definition of meter profiles and policies: In the case of the data plane adding flow rules to itself  (as opposed to the control plane adding flow rules to the data plane), the API requirement of pre-defining the profile and the policy results in a performance problem. This is because the driver needs to acquire the lock to the list of profiles/policies and to search for the profile/policy ID within the profile/policy list. Therefore, to avoid this issue, the API needs to allow passing the profile parameters (i.e. the full profile) and the policy parameters (i.e. the full policy) to the meter object creation/configuration.

2. Add the packet color to the list of possible match items: This would make the meter policy specification redundant, as the packet color that is set by a meter object could be used as match field into a subsequent table (group) to apply the actions that currently have to be specified as part of the meter policy. Therefore, in this case, passing the policy to the meter object creation/configuration is redundant, and therefore the API should accept passing a NULL policy as well as a valid policy.

3. The flow METER action needs to continue to imply the implicit action of setting the packet color (internal meta-data).

4. Translation of meter profile (i.e. srTCM/trTCM rates and bucket sizes) to the implementation-dependent low-level values: This is still required, as it is taking significant cycles, which is a problem when the data plane is adding flow rules to itself. What should be avoided is the registration of the output of the translation as a pre-defined profile ID.

5. Proposal to create/configure a meter object as part of an rte_flow action. Question to be addressed by Alexander Kozyrev and Ori Kam: How do we get an ID for the meter object for the purpose of (1) sharing the same meter object with other flows; (2) Freeing up the meter object after the flow is removed (in fact, after all the flows sharing the same meter object are removed).

6. Alexander Kozyrev to provide pseudo-code for the meter operation with the new proposal:
	(1) meter creation;
	(2) meter sharing;
	(3) meter reconfiguration: do we need to remove the flow/flows using the meter and re-add them with a new meter object that has updated configuration, or can we update the meter object itself (what API?);
	(4) meter free.

Regards,
Cristian

> -----Original Appointment-----
> From: Alexander Kozyrev <akozyrev@nvidia.com>
> Sent: Friday, May 13, 2022 10:37 PM
> To: Alexander Kozyrev; Ori Kam; Jerin Jacob; Dumitrescu, Cristian; NBU-
> Contact-Thomas Monjalon (EXTERNAL); Andrew Rybchenko;
> Vipin.Varghese@amd.com; Ajit Khaparde; Ferruh Yigit
> Cc: Ray Kinsella; Sunil Kumar Kori; Ivan Malov; Awal, Mohammad Abdul; Zhang,
> Qi Z; Richardson, Bruce; Konstantin Ananyev; Singh, Jasvinder; dev@dpdk.org
> Subject: [RFC] ethdev: datapath-focused meter actions, continue
> When: 19 May 2022 15:00-16:00 (UTC) Coordinated Universal Time.
> Where: https://meet.jit.si/DPDK
> 
> Agenda: continue discussion about proposed improvements to Flow API in
> regards to Meter handling (slides attached).