Re: [PATCH v2 0/4] ethdev: separate metering and marking from policing

[Jerin Jacob <jerinjacobk@gmail.com>]

On Thu, May 26, 2022 at 6:51 PM Jerin Jacob <jerinjacobk@gmail.com> wrote:
>
> On Sun, May 22, 2022 at 4:21 PM Alexander Kozyrev <akozyrev@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-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 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.