> -----Original Message----- > From: Ajit Khaparde <ajit.khapa...@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 <akozy...@nvidia.com> wrote: > > > > On Thursday, May 19, 2022 13:35 Dumitrescu, Cristian > > <cristian.dumitre...@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);
