On Fri, Dec 22, 2017 at 11:03 AM, Zhang, Qi Z [off-list ref] wrote:

quoted

On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang [off-list ref] wrote:

quoted

Add new APIs to support flow timeout, application is able to 1. Setup
the time duration of a flow, the flow is expected to be deleted
automatically when timeout.

Can you explain how the application (OVS) is expected to use this API?
It will help to better understand the motivation here...

I think the purpose of the APIs is to expose the hardware feature that support
flow auto delete with a timeout.
As I know, for OVS, every flow in flow table will have time duration
A flow be offloaded to hardware is still required to be deleted in specific time,
I think these APIs help OVS to take advantage HW feature and simplify the flow
aging management

Are you sure this will allow OVS to 'fire-and-forget' about the rule removal?
or will OVS anyway do rule cleanup from application tables?

Do you know if OVS flow timers are (or can be) re-armed in different
use cases? e.g. extending the timeout duration if traffic is still
flowing?

quoted

Are you trying to move the aging timer from application code into the PMD?
or can your HW remove/disable/inactivate a flow at certain time semantics
without software context?

Yes, it for hardware feature.

So if the hardware auto removes the hardware steering entry, what
software part deletes the rte_flow handle?
What software part triggers the application callback? from what
context? will locks be required?

How do you prevent races between application thread and the context
deleting/accessing the rte_flow handle?
I mean in cases that application wants to delete the flow before the
timeout expires, but actually it is same time hardware deletes it.

Alex