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

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

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