On Sun, May 22, 2022 at 4:21 PM Alexander Kozyrev <akozy...@nvidia.com> wrote: > > 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-akozy...@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 overall approach looks good to me. Could you update doc/guides/prog_guide/traffic_metering_and_policing.rst for the new scheme. I think, we need to add "struct rte_mtr_capabilities" one more filed for the capability for the application to query to pick one way or another or both.
