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 <akozy...@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.vargh...@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).
