From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dumitrescu, Cristian" Subject: Re: [RFC 3/3] rte_flow: add new action for traffic metering and policing Date: Tue, 6 Jun 2017 18:37:57 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BA6560F@IRSMSX108.ger.corp.intel.com> References: <1496162653-137817-1-git-send-email-cristian.dumitrescu@intel.com> <1496162653-137817-4-git-send-email-cristian.dumitrescu@intel.com> <20170601151335.GJ1758@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "thomas@monjalon.net" , "jerin.jacob@caviumnetworks.com" , "hemant.agrawal@nxp.com" , "Doherty, Declan" , "Wiles, Keith" To: Adrien Mazarguil Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 7E9B34BE1 for ; Tue, 6 Jun 2017 20:38:00 +0200 (CEST) In-Reply-To: <20170601151335.GJ1758@6wind.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Adrien, Thanks for reviewing this proposal. > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Thursday, June 1, 2017 4:14 PM > To: Dumitrescu, Cristian > Cc: dev@dpdk.org; thomas@monjalon.net; > jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com; Doherty, > Declan ; Wiles, Keith > Subject: Re: [RFC 3/3] rte_flow: add new action for traffic metering and > policing >=20 > Hi Cristian, >=20 > On Tue, May 30, 2017 at 05:44:13PM +0100, Cristian Dumitrescu wrote: > > Signed-off-by: Cristian Dumitrescu > > --- > > lib/librte_ether/rte_flow.h | 22 ++++++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h > > index c47edbc..2942ca7 100644 > > --- a/lib/librte_ether/rte_flow.h > > +++ b/lib/librte_ether/rte_flow.h > > @@ -881,6 +881,14 @@ enum rte_flow_action_type { > > * See struct rte_flow_action_vf. > > */ > > RTE_FLOW_ACTION_TYPE_VF, > > + > > + /** > > + * Traffic metering and policing (MTR). > > + * > > + * See struct rte_flow_action_meter. > > + * See file rte_mtr.h for MTR object configuration. > > + */ > > + RTE_FLOW_ACTION_TYPE_METER, > > }; > > > > /** > > @@ -974,6 +982,20 @@ struct rte_flow_action_vf { > > }; > > > > /** > > + * RTE_FLOW_ACTION_TYPE_METER > > + * > > + * Traffic metering and policing (MTR). > > + * > > + * Packets matched by items of this type can be either dropped or pass= ed > to the > > + * next item with their color set by the MTR object. > > + * > > + * Non-terminating by default. > > + */ > > +struct rte_flow_action_meter { > > + uint32_t mtr_id; /**< MTR object ID created with rte_mtr_create(). > */ > > +}; > > + > > +/** > > * Definition of a single action. > > * > > * A list of actions is terminated by a END action. >=20 > Assuming this action is provided to the underlying PMD, can you describe > what happens next; what is a PMD supposed to do when creating the flow > rule > and the impact on its data path? >=20 Metering is just another flow action that needs to be supported by rte_flow= API. Typically, NICs supporting this action have an array of metering & policing= contexts on their data path, which are abstracted as MTR objects in our AP= I. - rte_mtr_create() configures an MTR object, with no association to any of = the known flows yet. - On NIC side, the driver configures one of the available metering & polic= ing contexts. - rte_flow_create() defines the flow (match rule) and its set of actions, w= ith metering & policing as one of the actions. - On NIC side, the driver configures a flow/filter for traffic classificat= ion/distribution/bifurcation, with the metering & policing context enabled = for this flow. At run-time, any packet matching this flow will execute this action, which = involves metering (packet is assigned a color) and policing (packet may be = recolored or dropped, as configured), with stats being updated as well. > It looks like mtr_id is arbitrarily set by the user calling > rte_mtr_create(), which means the PMD has to look up the associated MTR > context somehow. >=20 > How about making the rte_mtr_create() API return an opaque rte_mtr > object > pointer provided back to all API functions as well as through this action > instead, and not leave it up to the user? >=20 Of course, it can be done this way as well, but IMHO probably not the best = idea from the application perspective. We had a similar discussion when we = defined the ethdev traffic management API [1]. Object handles can be integers, void pointers or pointers to opaque structu= res, and each of these approaches are allowed and used by DPDK APIs. Here i= s an example why I think using integers for MTR object handle makes the lif= e of the application easier: - Let's assume we have several actions for a flow (a1, a2, a3, ...). - When handles are pointers to opaque structures, app typically needs to sa= ve all of them in a per flow data structure: struct a1 *p1, struct a2 *p2, = struct a3 *p3. -This results in increased complexity and size for the app tables, which c= an be avoided. - When handles are integers generated by the app as opposed of driver, the = app can simply use a single index - let's cal it flow_id - and register it = as the handle to each of these flow actions. - No more fake tables. - No more worries about the pointer being valid in one address space and n= ot valid in another. There is some handle lookup to be done by the driver, but this is a trivial= task, and checking the validity of the handle (input parameter) is the fi= rst thing done by any API function, regardless of which handle style is use= d. [1] http://www.dpdk.org/ml/archives/dev/2017-February/057368.html > -- > Adrien Mazarguil > 6WIND Regards, Cristian