Hi Sugesh,

On Mon, Dec 12, 2016 at 10:20:18AM +0000, Chandran, Sugesh wrote:

Hi Adrien,

Regards
_Sugesh

quoted

-----Original Message-----
From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
Sent: Friday, December 9, 2016 4:39 PM
To: Chandran, Sugesh <redacted>
Cc: Kevin Traynor <redacted>; dev@dpdk.org; Thomas
Monjalon [off-list ref]; De Lara Guarch, Pablo
[off-list ref]; Olivier Matz [off-list ref];
sugesh.chandran@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:
[...]

quoted

quoted

quoted

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.

quoted

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.

quoted

quoted

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.

quoted

This way the complexity of determining the mode by itself will be taken

away from PMD.

quoted

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.

quoted

This way its simple, clean and very predictive though it needs to define an

additional profile_define APIs.

quoted

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.

quoted

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?

Will do, I'll mention it in the "future evolutions" section.

-- 
Adrien Mazarguil
6WIND