From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <sugesh.chandran@intel.com> Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 644812C8 for <dev@dpdk.org>; Mon, 12 Dec 2016 11:20:43 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 12 Dec 2016 02:20:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,335,1477983600"; d="scan'208";a="1097958103" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 12 Dec 2016 02:20:41 -0800 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Dec 2016 10:20:19 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.79]) by irsmsx111.ger.corp.intel.com ([169.254.2.55]) with mapi id 14.03.0248.002; Mon, 12 Dec 2016 10:20:19 +0000 From: "Chandran, Sugesh" <sugesh.chandran@intel.com> To: Adrien Mazarguil <adrien.mazarguil@6wind.com> CC: Kevin Traynor <ktraynor@redhat.com>, "dev@dpdk.org" <dev@dpdk.org>, "Thomas Monjalon" <thomas.monjalon@6wind.com>, "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>, Olivier Matz <olivier.matz@6wind.com> Thread-Topic: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API Thread-Index: AQHSQCYBGHBxiz6sm06ZxWXdKPvFC6Dx40iAgAD4jACAAmPWAIAGCHSggAMBoQCAAVlR8IAAUg8AgAQ9XrA= Date: Mon, 12 Dec 2016 10:20:18 +0000 Message-ID: <2EF2F5C0CC56984AA024D0B180335FCB13EC4F76@IRSMSX102.ger.corp.intel.com> References: <cover.1471632644.git.adrien.mazarguil@6wind.com> <cover.1479309719.git.adrien.mazarguil@6wind.com> <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> <2EF2F5C0CC56984AA024D0B180335FCB13EC4696@IRSMSX102.ger.corp.intel.com> <20161209163846.GN10340@6wind.com> In-Reply-To: <20161209163846.GN10340@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZmQ0OTkyNzQtMTE0My00MTI1LWEyN2QtNjc5YWUyYjYyZDhkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlwvZXFTT1wvd3FZc3ZDZzJ6b0JSeVRzMVwvNUViYTJ6VTNvbHMxMFhJTmRvdnM9In0= x-ctpclassification: CTP_IC 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 12 Dec 2016 10:20:44 -0000 Hi Adrien, Regards _Sugesh > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Friday, December 9, 2016 4:39 PM > To: Chandran, Sugesh <sugesh.chandran@intel.com> > Cc: Kevin Traynor <ktraynor@redhat.com>; dev@dpdk.org; Thomas > Monjalon <thomas.monjalon@6wind.com>; De Lara Guarch, Pablo > <pablo.de.lara.guarch@intel.com>; Olivier Matz <olivier.matz@6wind.com>; > sugesh.chandran@intel.comn > Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API >=20 > Hi Sugesh, >=20 > On Fri, Dec 09, 2016 at 12:18:03PM +0000, Chandran, Sugesh wrote: > [...] > > > > 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 mode, > > > 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.? > > > > > > 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. > > > > > > I think we've discussed an atomic (commit-based) mode of operation > > > through separate functions as well, where the application would > > > attempt to create a bunch of rules at once, possibly making it > > > easier for PMDs to determine the most appropriate mode of operation > for the device. > > > > > > All of these may be added later according to users feedback once the > > > basic 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 defin= e a > profile/mode of the device. > > This way the complexity of determining the mode by itself will be taken > away from PMD. > > Looking at the P4 enablement patches in OVS, the mode definition APIs > > can be used in conjunction > > P4 behavioral model. > > For eg: A P4 model for a L2 switch operate OVS as a L2 switch. Using > > the mode definition APIs Its possible to impose the same behavioral mod= el > in the hardware too. > > This way its simple, clean and very predictive though it needs to defin= e an > additional profile_define APIs. > > I am sorry to provide the comment at this stage, However looking at > > the adoption of ebpf, P4 make me to think this way. > > What do you think? >=20 > What you suggest (device profile configuration) would be done by a separa= te > function in any case, so as long as everyone agrees on a generic method t= o > do so, no problem with extending rte_flow. By default in the meantime we'= ll > have to rely on PMDs to make the right decision. [Sugesh] I am fine with PMD is making the decision on profile/mode selectio= n in Default case. However we must provide an option for the application to defi= ne a mode and PMD must honor with it to avoid making an invalid mode change. >=20 > Do you think it has to be defined from the beginning? [Sugesh] I feel it's going to be another big topic to decide how proposed m= ode implementation will be looks like, What should be available modes and etc. So I am OK to consider as its not = part of this flow API definition for now. However its good to mention that in the API comments section to be aware. D= o you agree that? >=20 > -- > Adrien Mazarguil > 6WIND