On Thu, May 26, 2022 at 6:51 PM Jerin Jacob <jerinjac...@gmail.com> wrote: > > 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.
Also, I think, the driver patches need to submit and merge before rc2 to avoid the case where there is no single implementation for API.
