RE: [RFC] ethdev: datapath-focused meter actions, continue

[Ori Kam <orika@nvidia.com>]

> -----Original Message-----
> From: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Sent: Sunday, May 22, 2022 8:01 AM
> Subject: Re: [RFC] ethdev: datapath-focused meter actions, continue
> 
> On Sat, May 21, 2022 at 7:49 PM Alexander Kozyrev <akozyrev@nvidia.com> wrote:
> >
> > On Thursday, May 19, 2022 13:35 Dumitrescu, Cristian <cristian.dumitrescu@intel.com>:
> > > Here are a few takeaways of mine, with a few actions for Alex and Ori:
> >
> > Thank you, Cristian, for compiling these takeaways. Great summary of the discussion.
> Agree.
> 
+1

> >
> > > 6. Alexander Kozyrev to provide pseudo-code for the meter operation with
> > > the new proposal:
> 
> I was wondering how the PMD and application can negotiate whether
> to use the old model or the new model.
> Maybe the application can determine if the PMD supports the traditional model or
> the new model by checking rte_mtr_meter_profile_get or rte_mtr_meter_policy_get?
> Or use something else?
> 
Good idea, and it can know if the new API is not supported, like any other rte_flow API validate it.

> 
> > >       (1) meter creation;
> > >       (2) meter sharing;
> > >       (3) meter reconfiguration: do we need to remove the flow/flows
> > > using the meter and re-add them with a new meter object that has updated
> > > configuration, or can we update the meter object itself (what API?);
> > >       (4) meter free.
> >
> > 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_MARK(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_MARK(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_profile_get(profile_id);
> > handle = rte_flow_action_handle_create(action= METER_MARK(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);