Hi Adrien, Regards _Sugesh
> -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com] > Sent: Friday, December 9, 2016 4:39 PM > To: Chandran, Sugesh <sugesh.chand...@intel.com> > Cc: Kevin Traynor <ktray...@redhat.com>; dev@dpdk.org; Thomas > Monjalon <thomas.monja...@6wind.com>; De Lara Guarch, Pablo > <pablo.de.lara.gua...@intel.com>; Olivier Matz <olivier.m...@6wind.com>; > sugesh.chand...@intel.comn > Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API > > 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. [Sugesh] I am fine with PMD is making the decision on profile/mode selection in Default case. However we must provide an option for the application to define a mode and PMD must honor with it to avoid making an invalid mode change. > > 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 mode 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. Do you agree that? > > -- > Adrien Mazarguil > 6WIND
