On Fri, Dec 22, 2017 at 11:03 AM, Zhang, Qi Z <qi.z.zh...@intel.com> wrote: >> On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang <qi.z.zh...@intel.com> wrote: >> > 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? >> 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
