Hi Adrien,
Thanks for your clarification.  Most of my questions are clear, but still something may need to be discussed, comment below.

-----Original Message-----
From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
Sent: Thursday, July 7, 2016 6:27 PM
To: Lu, Wenzhuo
Cc: dev@dpdk.org; Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody;
Ajit Khaparde; Rahul Lakkireddy; Jan Medala; John Daley; Chen, Jing D; Ananyev,
Konstantin; Matej Vido; Alejandro Lucero; Sony Chacko; Jerin Jacob; De Lara
Guarch, Pablo; Olga Shern
Subject: Re: [RFC] Generic flow director/filtering/classification API

Hi Lu Wenzhuo,

Thanks for your feedback, I'm replying below as well.

On Thu, Jul 07, 2016 at 07:14:18AM +0000, Lu, Wenzhuo wrote:

quoted

Hi Adrien,
I have some questions, please see inline, thanks.

quoted

-----Original Message-----
From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
Sent: Wednesday, July 6, 2016 2:17 AM
To: dev@dpdk.org
Cc: Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody; Ajit
Khaparde; Rahul Lakkireddy; Lu, Wenzhuo; Jan Medala; John Daley;
Chen, Jing D; Ananyev, Konstantin; Matej Vido; Alejandro Lucero;
Sony Chacko; Jerin Jacob; De Lara Guarch, Pablo; Olga Shern
Subject: [RFC] Generic flow director/filtering/classification API


Requirements for a new API:

- Flexible and extensible without causing API/ABI problems for existing
  applications.
- Should be unambiguous and easy to use.
- Support existing filtering features and actions listed in `Filter types`_.
- Support packet alteration.
- In case of overlapping filters, their priority should be well documented.

Does that mean we don't guarantee the consistent of priority? The priority can

be different on different NICs. So the behavior of the actions  can be different.
Right?

No, the intent is precisely to define what happens in order to get a consistent
result across different devices, and document cases with undefined behavior.
There must be no room left for interpretation.

For example, the API must describe what happens when two overlapping filters
(e.g. one matching an Ethernet header, another one matching an IP header)
match a given packet at a given priority level.

It is documented in section 4.1.1 (priorities) as "undefined behavior".
Applications remain free to do it and deal with consequences, at least they know
they cannot expect a consistent outcome, unless they use different priority
levels for both rules, see also 4.4.5 (flow rules priority).

quoted

Seems the users still need to aware the some details of the HW? Do we need

to add the negotiation for the priority?

Priorities as defined in this document may not be directly mappable to HW
capabilities (e.g. HW does not support enough priorities, or that some corner
case make them not work as described), in which case the PMD may choose to
simulate priorities (again 4.4.5), as long as the end result follows the
specification.

So users must not be aware of some HW details, the PMD does and must
perform the needed workarounds to suit their expectations. Users may only be
impacted by errors while attempting to create rules that are either unsupported
or would cause them (or existing rules) to diverge from the spec.

The problem is sometime the priority of the filters is fixed according to HW's implementation. For example, on ixgbe, n-tuple has a higher priority than flow director. What's the right behavior of PMD if APP want to create a flow director rule which has a higher or even equal priority than an existing n-tuple rule? Should PMD return fail? 
If so, do we need more fail reasons? According to this RFC, I think we need return " EEXIST: collision with an existing rule. ", but it's not very clear, APP doesn't know the problem is priority, maybe more detailed reason is helpful.

quoted

quoted

Behavior
--------

- API operations are synchronous and blocking (``EAGAIN`` cannot be
  returned).

- There is no provision for reentrancy/multi-thread safety, although nothing
  should prevent different devices from being configured at the same
  time. PMDs may protect their control path functions accordingly.

- Stopping the data path (TX/RX) should not be necessary when managing

flow

quoted

quoted

  rules. If this cannot be achieved naturally or with workarounds (such as
  temporarily replacing the burst function pointers), an appropriate error
  code must be returned (``EBUSY``).

PMD cannot stop the data path without adding lock. So I think if some rules

cannot be applied without stopping rx/tx, PMD has to return fail.

quoted

Or let the APP to stop the data path.

Agreed, that is the intent. If the PMD cannot touch flow rules for some reason
even after trying really hard, then it just returns EBUSY.

Perhaps we should write down that applications may get a different outcome
after stopping the data path if they get EBUSY?

Agree, it's better to describe more about the APP. BTW, I checked the behavior of ixgbe/igb, I think we can add/delete filters during runtime. Hopefully we'll not hit too many EBUSY problems on other NICs :)

quoted

quoted

- PMDs, not applications, are responsible for maintaining flow rules
  configuration when stopping and restarting a port or performing other
  actions which may affect them. They can only be destroyed explicitly.

Don’t understand " They can only be destroyed explicitly."

This part says that as long as an application has not called
rte_flow_destroy() on a flow rule, it never disappears, whatever happens to the
port (stopped, restarted). The application is not responsible for re-creating rules
after that.

Note that according to the specification, this may translate to not being able to
stop a port as long as a flow rule is present, depending on how nice the PMD
intends to be with applications. Implementation can be done in small steps with
minimal amount of code on the PMD side.

Does it mean PMD should store and maintain all the rules? Why not let rte do that? I think if PMD maintain all the rules, it means every kind of NIC should have a copy of code for the rules. But if rte do that, only one copy of code need to be maintained, right?
When the port is stopped and restarted, rte can reconfigure the rules. Is the concern that PMD may adjust the sequence of the rules according to the priority, so every NIC has a different list of rules? But PMD can adjust them again when rte reconfiguring the rules.

--
Adrien Mazarguil
6WIND