From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 80946374F for ; Fri, 9 Dec 2016 13:18:07 +0100 (CET) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP; 09 Dec 2016 04:18:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,324,1477983600"; d="scan'208";a="40581618" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga005.jf.intel.com with ESMTP; 09 Dec 2016 04:18:04 -0800 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 9 Dec 2016 12:18:03 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.79]) by IRSMSX156.ger.corp.intel.com ([169.254.3.74]) with mapi id 14.03.0248.002; Fri, 9 Dec 2016 12:18:04 +0000 From: "Chandran, Sugesh" To: Adrien Mazarguil CC: Kevin Traynor , "dev@dpdk.org" , Thomas Monjalon , "De Lara Guarch, Pablo" , Olivier Matz , "sugesh.chandran@intel.comn" Thread-Topic: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API Thread-Index: AQHSQCYBGHBxiz6sm06ZxWXdKPvFC6Dx40iAgAD4jACAAmPWAIAGCHSggAMBoQCAAVlR8A== Date: Fri, 9 Dec 2016 12:18:03 +0000 Message-ID: <2EF2F5C0CC56984AA024D0B180335FCB13EC4696@IRSMSX102.ger.corp.intel.com> References: <1c8a8e4fec73ed33836f1da9525b1b8b53048518.1479309720.git.adrien.mazarguil@6wind.com> <59393e58-6c85-d2e5-1aab-a721fe9c933e@redhat.com> <20161201083652.GI10340@6wind.com> <7f65ba09-e6fe-d97a-6ab5-97e84a828a81@redhat.com> <2EF2F5C0CC56984AA024D0B180335FCB13EC330D@IRSMSX102.ger.corp.intel.com> <20161208150908.GJ10340@6wind.com> In-Reply-To: <20161208150908.GJ10340@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTY2MjBlMGQtMjNkOC00ZmRmLWIzMGItYzVkZjQ3YjdkZGJlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiJHWTNaSFBvWEZVY2FUeFYzOTBjRHlmdG0zQktvQzIwTmJiZ2cwSUZlbW1vPSJ9 x-ctpclassification: CTP_PUBLIC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API 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: Fri, 09 Dec 2016 12:18:08 -0000 Hi Adrien, Thank you for your comments, Please see the reply below. Regards _Sugesh > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Thursday, December 8, 2016 3:09 PM > To: Chandran, Sugesh > Cc: Kevin Traynor ; dev@dpdk.org; Thomas > Monjalon ; De Lara Guarch, Pablo > ; Olivier Matz ; > sugesh.chandran@intel.comn > Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API >=20 > Hi Sugesh, >=20 > On Tue, Dec 06, 2016 at 06:11:38PM +0000, Chandran, Sugesh wrote: > [...] > > > >>> +int > > > >>> +rte_flow_validate(uint8_t port_id, > > > >>> + const struct rte_flow_attr *attr, > > > >>> + const struct rte_flow_item pattern[], > > > >>> + const struct rte_flow_action actions[], > > > >>> + struct rte_flow_error *error); > > > >> > > > >> Why not just use rte_flow_create() and get an error? Is it less > > > >> disruptive to do a validate and find the rule cannot be created, > > > >> than using a create directly? > > > > > > > > The rationale can be found in the original RFC, which I'll convert > > > > to actual documentation in v2. In short: > > > > > > > > - Calling rte_flow_validate() before rte_flow_create() is useless s= ince > > > > rte_flow_create() also performs validation. > > > > > > > > - We cannot possibly express a full static set of allowed flow rule= s, even > > > > if we could, it usually depends on the current hardware configura= tion > > > > therefore would not be static. > > > > > > > > - rte_flow_validate() is thus provided as a replacement for capabil= ity > > > > flags. It can be used to determine during initialization if the u= nderlying > > > > device can support the typical flow rules an application might wa= nt to > > > > provide later and do something useful with that information (e.g. > always > > > > use software fallback due to HW limitations). > > > > > > > > - rte_flow_validate() being a subset of rte_flow_create(), it is > essentially > > > > free to expose. > > > > > > make sense now, thanks. > > [Sugesh] : We had this discussion earlier at the design stage about > > the time taken for programming the hardware, and how to make it > > deterministic. How about having a timeout parameter as well for the > > rte_flow_* If the hardware flow insert is timed out, error out than > > waiting indefinitely, so that application have some control over The > > time to program the flow. It can be another set of APIs something > > like, rte_flow_create_timeout() >=20 > Yes as discussed the existing API does not provide any timing constraints= to > PMDs, validate() and create() may take forever to complete, although PMDs > are strongly encouraged to take as little time as possible. >=20 > Like you suggested, this could be done through distinct API calls. The > validate() function would also have its _timeout() counterpart since the = set > of possible rules could be restricted in that mode. [Sugesh] Thanks!. Looking forward to see an api set with that implementatio= n as well=20 in the future :). I feel it's a must from the user application point of vie= w. >=20 > > Are you going to provide any control over the initialization of NIC > > to define the capability matrices For eg; To operate in a L3 router mod= e, > software wanted to initialize the NIC port only to consider the L2 and L3 > fields. > > I assume the initialization is done based on the first rules that are > programmed into the NIC.? >=20 > Precisely, PMDs are supposed to determine the most appropriate device > mode to use in order to handle the requested rules. They may even switch > to another mode if necessary assuming this does not break existing > constraints. >=20 > I think we've discussed an atomic (commit-based) mode of operation > through separate functions as well, where the application would attempt t= o > create a bunch of rules at once, possibly making it easier for PMDs to > determine the most appropriate mode of operation for the device. >=20 > All of these may be added later according to users feedback once the basi= c > API has settled. [Sugesh] Yes , we discussed about this before. However I feel that, it make= sense to provide some flexibility to the user/application to define a profile/mod= e of the device. This way the complexity of determining the mode by itself will be taken awa= y from PMD. Looking at the P4 enablement patches in OVS, the mode definition APIs can b= e used in conjunction P4 behavioral model.=20 For eg: A P4 model for a L2 switch operate OVS as a L2 switch. Using the mo= de definition APIs Its possible to impose the same behavioral model in the hardware too.=20 This way its simple, clean and very predictive though it needs to define an= additional profile_define APIs. I am sorry to provide the comment at this stage, However looking at the ad= option of ebpf, P4 make me to think this way. What do you think? >=20 > -- > Adrien Mazarguil > 6WIND