From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id D86312E83 for ; Wed, 12 Jul 2017 20:06:35 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2017 11:06:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,351,1496127600"; d="scan'208";a="1150878867" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga001.jf.intel.com with ESMTP; 12 Jul 2017 11:06:25 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.133]) by IRSMSX107.ger.corp.intel.com ([169.254.10.129]) with mapi id 14.03.0319.002; Wed, 12 Jul 2017 19:06:24 +0100 From: "Dumitrescu, Cristian" To: Adrien Mazarguil CC: "dev@dpdk.org" , "thomas@monjalon.net" , "jerin.jacob@caviumnetworks.com" , "hemant.agrawal@nxp.com" , "Doherty, Declan" , "Wiles, Keith" Thread-Topic: [RFC 3/3] rte_flow: add new action for traffic metering and policing Thread-Index: AQHS2umx1Rf3I9lDAUOHM8/fCiPOYqIYG3WggDU+OQCAA14SUA== Date: Wed, 12 Jul 2017 18:06:24 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BA7F587@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> <3EB4FA525960D640B5BDFFD6A3D891267BA6560F@IRSMSX108.ger.corp.intel.com> <20170710152100.GW19852@6wind.com> In-Reply-To: <20170710152100.GW19852@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODZlMTk3YjEtNWQxNC00Mjg2LWFlZWQtODFhZGI1ZmRmZmI3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlZXb1UrUWtCSTFKSlFKMkJCbnRYNXVpenpFVHZHVjBlOXdwaWJFdytvNVU9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC 3/3] rte_flow: add new action for traffic metering and policing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 18:06:36 -0000 Hi Adrien, > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Monday, July 10, 2017 4:21 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 > Took me a while to reply and I didn't see any update in the meantime, is > this RFC still relevant? Yes, absolutely! >=20 > More comments below. >=20 Thanks for continuing to look into this! I am actively looking for partners= to evolve this API further and make it a good fit for DPDK devices. Now th= at Traffic Management API got merged, I can hopefully come back and spend m= ore time on this. > On Tue, Jun 06, 2017 at 06:37:57PM +0000, Dumitrescu, Cristian wrote: > > 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 > > > > > > Hi Cristian, > > > > > > 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_flo= w.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 > passed > > > 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. > > > > > > Assuming this action is provided to the underlying PMD, can you descr= ibe > > > what happens next; what is a PMD supposed to do when creating the > flow > > > rule > > > and the impact on its data path? > > > > > > > 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 & poli= cing > contexts on their data path, which are abstracted as MTR objects in our A= PI. > > - 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 & > policing contexts. > > - rte_flow_create() defines the flow (match rule) and its set of action= s, > with metering & policing as one of the actions. > > - On NIC side, the driver configures a flow/filter for traffic > classification/distribution/bifurcation, with the metering & policing con= text > enabled for this flow. > > > > At run-time, any packet matching this flow will execute this action, wh= ich > involves metering (packet is assigned a color) and policing (packet may b= e > recolored or dropped, as configured), with stats being updated as well. >=20 > Thanks, this description should be part of the documentation in the final > patch. The relationship between rte_mtr and rte_flow objects must be > described as well, for instance making clear that one cannot remove a mtr > object if a flow rule depends on it. >=20 Yes, took the note to document this. Will expand this is Doxygen 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. > > > > > > 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 ac= tion > > > instead, and not leave it up to the user? > > > > > > > Of course, it can be done this way as well, but IMHO probably not the b= est > idea from the application perspective. We had a similar discussion when w= e > defined the ethdev traffic management API [1]. > > > > Object handles can be integers, void pointers or pointers to opaque > structures, and each of these approaches are allowed and used by DPDK > APIs. Here is an example why I think using integers for MTR object handle > makes the life 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 t= o > save 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 can 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 regist= er 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 not valid in another. > > > > There is some handle lookup to be done by the driver, but this is a tri= vial > task, and checking the validity of the handle (input parameter) is the f= irst > thing done by any API function, regardless of which handle style is used. >=20 > All this sounds reasonable from the control plane standpoint. My comment > was > more generally besides the above rte_flow action, are we sure mtr_id will > never be used to perform actions from the data plane? >=20 Yes, we are sure. This object ID is just used for configuration. Even for the SW fall-back case (see the librte_meter) this ID is not used o= n data path. When flow is added with this action, the meter context is simp= ly initialized in the flow table entry and used directly from here, no look= up takes place on data path. > Otherwise driver lookup is perhaps a trivial task but is nonetheless > expensive. This step can be avoided if mtr_id contains enough information= to > locate the related object as fast as possible inside the PMD without the > need for an intermediate lookup table. >=20 Yes, agreed, any ID lookup/translation on data path is expensive and has to= be avoided. As stated above, there is no ID lookup/translation on the data= path to be performed here. > In which case, making mtr_id a pointer-sized opaque value (e.g. uintptr_t= ) > provided by the PMD when calling rte_mtr_create() gives more flexibility = to > the PMD. For some, a basic index value could be enough while for others, = an > intermediate structure could be necessary. >=20 > Admittedly this is exactly the same as a pointer type to an opaque object= , > address space-related issues would have to be managed by the PMD either > way. Applications are not supposed to dereference such objects. >=20 Yes, these are the typical methods to avoid any ID lookup/translation on da= ta path, but not needed here. > > [1] http://www.dpdk.org/ml/archives/dev/2017-February/057368.html >=20 > -- > Adrien Mazarguil > 6WIND Regards, Cristian