From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: [PATCH 01/22] ethdev: introduce generic flow API Date: Fri, 9 Dec 2016 17:38:46 +0100 Message-ID: <20161209163846.GN10340@6wind.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> <2EF2F5C0CC56984AA024D0B180335FCB13EC4696@IRSMSX102.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kevin Traynor , "dev@dpdk.org" , Thomas Monjalon , "De Lara Guarch, Pablo" , Olivier Matz , "sugesh.chandran@intel.comn" To: "Chandran, Sugesh" Return-path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id B719E3772 for ; Fri, 9 Dec 2016 17:38:55 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id a197so32010711wmd.0 for ; Fri, 09 Dec 2016 08:38:55 -0800 (PST) Content-Disposition: inline In-Reply-To: <2EF2F5C0CC56984AA024D0B180335FCB13EC4696@IRSMSX102.ger.corp.intel.com> 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 Sugesh, 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 define 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 model in the hardware too. > 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 adoption of ebpf, P4 make me > to think this way. > What do you think? What you suggest (device profile configuration) would be done by a separate function in any case, so as long as everyone agrees on a generic method to 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. Do you think it has to be defined from the beginning? -- Adrien Mazarguil 6WIND