[v3,0/7] ethdev: separate metering and marking from policing

  Extend Metering and Marking support in the Flow API:
1. Add METER_COLOR item to match Color Marker set by a Meter.
2. Add the ability to set Color Marker via modify_field Flow API.
3. Add Meter API to get profile/policy objects.
4. Add METER_MARK action to perform Meter color metering and marking.
Provide greater flexibility in how Metering can be used.

RFC: https://patchwork.dpdk.org/project/dpdk/cover/20220502200439.4100965-1-akozyrev@nvidia.com/

Traditional Meter Usage:

profile_id = rte_mtr_meter_profile_add(RFC_params);
policy_id = rte_mtr_meter_policy_add(actions[RED/YELLOW/GREEN]);
meter_id = rte_mtr_create(profile_id, policy_id);
rte_flow_create(pattern=5-tuple,actions=METER(meter_id));

The METER action effectively translates to the following:
1. Metering a packet stream.
2. Marking packets with an appropriate color.
3. Jump to a policy group.
4. Match on a color.
5. Execute assigned policy actions for the color.

New Meter Usage Model:
profile_id = rte_mtr_meter_profile_add(RFC_params);
*profile_obj_ptr = rte_mtr_meter_profile_get(profile_id);
rte_flow_create(pattern=5-tuple,
				actions=METER(profile_obj_ptr),JUMP);
rte_flow_create(pattern=COLOR, actions=...);

The METER_MARK action effectively translates to the following:
1. Metering a packet stream.
2. Marking packets with an appropriate color.

A user is able to match the color later with the COLOR item.
In order to do this we add the JUMP action after the METER action.

3. Jump to a policy group.
4. Match on a color.
5. Execute actions for the color.

Here we decoupled the meter profile usage from the meter policy usage
for greater flexibility and got rid of any locks related to meter_id lookup.

Another example of the meter creation to mimic the old model entirely:
profile_id = rte_mtr_meter_profile_add(RFC_params);
*profile_obj_ptr = rte_mtr_meter_profile_get(profile_id);
policy_id = rte_mtr_meter_policy_add(actions[RED/YELLOW/GREEN]);
*policy_obj_ptr = rte_mtr_meter_policy_get(policy_id);
rte_flow_create(pattern=5-tuple,
				actions=METER(profile_obj_ptr, policy_obj_ptr));

In this case, we define the policy actions right away.
The main advantage is not having to lookup for profile_id/policy_id.

To free the meter obects we need to do the following:
rte_flow_destroy(flow_handle);
rte_mtr_meter_policy_delete(policy_id);
rte_mtr_meter_profile_delete(profile_id);.
profile_obj_ptr and policy_obj_ptr are no longer valid after that.

The meter profile configuration cannot be updated dynamically
with the current set of patches, but can be supported later on.
Now you have to destroy flows and profiles and recreate them.
But rte_mtr_meter_profile_update()/rte_mtr_meter_policy_update()
can have the corresponding siblings without mtr_id parameters.
In this case, we can update the config and all the flows using them.

The meter sharing is done via the indirect action Flow API:
profile_id = rte_mtr_meter_profile_add(RFC_params);
*profile_obj_ptr = rte_mtr_meter_prof8ile_get(profile_id);
handle = rte_flow_action_handle_create(action=METER(profile_obj_ptr, NULL));
flow1 = rte_flow_create(pattern=5-tuple-1, actions=INDIRECT(handle));
flow2 = rte_flow_create(pattern=5-tuple-2, actions=INDIRECT(handle));

Once we are done with the flow rules we can free everything.
rte_flow_destroy(flow1);
rte_flow_destroy(flow2);
rte_flow_action_handle_destroy(handle);
rte_mtr_meter_profile_delete(profile_id);

Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>

Alexander Kozyrev (7):
  ethdev: add meter color flow matching item
  ethdev: allow meter color marker modification
  ethdev: get meter profile/policy objects
  ethdev: add meter color mark flow action
  app/testpmd: add meter color flow matching item
  app/testpmd: allow meter color marker modification
  app/testpmd: add meter color mark flow action

 app/test-pmd/cmdline_flow.c                   | 213 +++++++++++++++++-
 app/test-pmd/config.c                         |  26 +++
 app/test-pmd/testpmd.h                        |   4 +
 doc/guides/prog_guide/rte_flow.rst            |  32 +++
 .../traffic_metering_and_policing.rst         |   7 +
 doc/guides/rel_notes/release_22_07.rst        |   7 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst   |   9 +
 lib/ethdev/rte_flow.c                         |   2 +
 lib/ethdev/rte_flow.h                         |  60 +++++
 lib/ethdev/rte_mtr.c                          |  41 ++++
 lib/ethdev/rte_mtr.h                          |  40 ++++
 lib/ethdev/rte_mtr_driver.h                   |  19 ++
 lib/ethdev/version.map                        |   2 +
 13 files changed, 461 insertions(+), 1 deletion(-)
  

> -----Original Message-----
> From: Alexander Kozyrev <akozyrev@nvidia.com>
> Sent: Wednesday, June 1, 2022 4:44 AM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> jerinjacobk@gmail.com; orika@nvidia.com; thomas@monjalon.net;
> ivan.malov@oktetlabs.ru; andrew.rybchenko@oktetlabs.ru;
> ferruh.yigit@xilinx.com; Awal, Mohammad Abdul
> <mohammad.abdul.awal@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> jerinj@marvell.com; ajit.khaparde@broadcom.com; Richardson, Bruce
> <bruce.richardson@intel.com>
> Subject: [PATCH v3 0/7] ethdev: separate metering and marking from
> policing
> 
> Extend Metering and Marking support in the Flow API:
> 1. Add METER_COLOR item to match Color Marker set by a Meter.
> 2. Add the ability to set Color Marker via modify_field Flow API.
> 3. Add Meter API to get profile/policy objects.
> 4. Add METER_MARK action to perform Meter color metering and marking.
> Provide greater flexibility in how Metering can be used.
> 
> RFC:
> https://patchwork.dpdk.org/project/dpdk/cover/20220502200439.4100965-
> 1-akozyrev@nvidia.com/
> 
> Traditional Meter Usage:
> 
> profile_id = rte_mtr_meter_profile_add(RFC_params);
> policy_id = rte_mtr_meter_policy_add(actions[RED/YELLOW/GREEN]);
> meter_id = rte_mtr_create(profile_id, policy_id);
> rte_flow_create(pattern=5-tuple,actions=METER(meter_id));
> 
> The METER action effectively translates to the following:
> 1. Metering a packet stream.
> 2. Marking packets with an appropriate color.
> 3. Jump to a policy group.
> 4. Match on a color.
> 5. Execute assigned policy actions for the color.
> 
> New Meter Usage Model:
> profile_id = rte_mtr_meter_profile_add(RFC_params);
> *profile_obj_ptr = rte_mtr_meter_profile_get(profile_id);
> rte_flow_create(pattern=5-tuple,
> 				actions=METER(profile_obj_ptr),JUMP);
> rte_flow_create(pattern=COLOR, actions=...);
> 
> The METER_MARK action effectively translates to the following:
> 1. Metering a packet stream.
> 2. Marking packets with an appropriate color.
> 
> A user is able to match the color later with the COLOR item.
> In order to do this we add the JUMP action after the METER action.
> 
> 3. Jump to a policy group.
> 4. Match on a color.
> 5. Execute actions for the color.
> 
> Here we decoupled the meter profile usage from the meter policy usage
> for greater flexibility and got rid of any locks related to meter_id lookup.
> 
> Another example of the meter creation to mimic the old model entirely:
> profile_id = rte_mtr_meter_profile_add(RFC_params);
> *profile_obj_ptr = rte_mtr_meter_profile_get(profile_id);
> policy_id = rte_mtr_meter_policy_add(actions[RED/YELLOW/GREEN]);
> *policy_obj_ptr = rte_mtr_meter_policy_get(policy_id);
> rte_flow_create(pattern=5-tuple,
> 				actions=METER(profile_obj_ptr,
> policy_obj_ptr));
> 
> In this case, we define the policy actions right away.
> The main advantage is not having to lookup for profile_id/policy_id.
> 
> To free the meter obects we need to do the following:
> rte_flow_destroy(flow_handle);
> rte_mtr_meter_policy_delete(policy_id);
> rte_mtr_meter_profile_delete(profile_id);.
> profile_obj_ptr and policy_obj_ptr are no longer valid after that.
> 
> The meter profile configuration cannot be updated dynamically
> with the current set of patches, but can be supported later on.
> Now you have to destroy flows and profiles and recreate them.
> But rte_mtr_meter_profile_update()/rte_mtr_meter_policy_update()
> can have the corresponding siblings without mtr_id parameters.
> In this case, we can update the config and all the flows using them.
> 
> The meter sharing is done via the indirect action Flow API:
> profile_id = rte_mtr_meter_profile_add(RFC_params);
> *profile_obj_ptr = rte_mtr_meter_prof8ile_get(profile_id);
> handle = rte_flow_action_handle_create(action=METER(profile_obj_ptr,
> NULL));
> flow1 = rte_flow_create(pattern=5-tuple-1, actions=INDIRECT(handle));
> flow2 = rte_flow_create(pattern=5-tuple-2, actions=INDIRECT(handle));
> 
> Once we are done with the flow rules we can free everything.
> rte_flow_destroy(flow1);
> rte_flow_destroy(flow2);
> rte_flow_action_handle_destroy(handle);
> rte_mtr_meter_profile_delete(profile_id);
> 
> Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
> 
> Alexander Kozyrev (7):
>   ethdev: add meter color flow matching item
>   ethdev: allow meter color marker modification
>   ethdev: get meter profile/policy objects
>   ethdev: add meter color mark flow action
>   app/testpmd: add meter color flow matching item
>   app/testpmd: allow meter color marker modification
>   app/testpmd: add meter color mark flow action
> 
>  app/test-pmd/cmdline_flow.c                   | 213 +++++++++++++++++-
>  app/test-pmd/config.c                         |  26 +++
>  app/test-pmd/testpmd.h                        |   4 +
>  doc/guides/prog_guide/rte_flow.rst            |  32 +++
>  .../traffic_metering_and_policing.rst         |   7 +
>  doc/guides/rel_notes/release_22_07.rst        |   7 +
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst   |   9 +
>  lib/ethdev/rte_flow.c                         |   2 +
>  lib/ethdev/rte_flow.h                         |  60 +++++
>  lib/ethdev/rte_mtr.c                          |  41 ++++
>  lib/ethdev/rte_mtr.h                          |  40 ++++
>  lib/ethdev/rte_mtr_driver.h                   |  19 ++
>  lib/ethdev/version.map                        |   2 +
>  13 files changed, 461 insertions(+), 1 deletion(-)
> 
> --
> 2.18.2

Hi Alexander,

Thanks very much for your pseudo-code detailing the updated meter & flow operation!

Should we setup another call sometime next week to go through it? I still see a few fuzzy things where we need to level set.

Regards,
Cristian