[dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support

[Wiles, Keith]

> On Dec 22, 2017, at 3:03 AM, Zhang, Qi Z <qi.z.zhang at intel.com> wrote:
> 
> Alex:
> 
>> -----Original Message-----
>> From: Alex Rosenbaum [mailto:rosenbaumalex at gmail.com]
>> Sent: Thursday, December 21, 2017 9:59 PM
>> To: Zhang, Qi Z <qi.z.zhang at intel.com>
>> Cc: adrien.mazarguil at 6wind.com; DPDK <dev at dpdk.org>; Doherty, Declan
>> <declan.doherty at intel.com>
>> Subject: Re: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support
>> 
>> On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang <qi.z.zhang at 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 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.

We also need to support a software timeout feature here and not just a hardware one. The reason is to make the APIs consistent across all hardware. If you are going to include hardware timeout then we need to add software supported timeout at the same time IMO.

> 
>> 
>> I would prefer to have the aging timer logic in a centralized location, leek the
>> application itself or some DPDK library. instead of having each PMD
>> implement its own software timers.
>> 
>> 
>>> 3. Register a callback function when a flow is deleted due to timeout.
>> 
>> Is the application 'struct rte_flow*' handle really deleted? or the flow was
>> removed from HW, just in-active at this time?
> 
> Here the flow is deleted, same thing happen as rte_flow_destroy and we need to call
> rte_flow_create to re-enable the flow. 
> I will add more explanation to avoid confusion in next release.

Sorry, I little late into this thread, but we can not have 1000 callbacks for each timeout and we need make sure we bunch up a number of timeouts at a time to make the feature more performant IMO. Maybe that discussed or address in the code.

> 
>> 
>> Can a flow be re-activated? or does this require a call to
>> rte_flow_destory() and ret_flow_create()?
>> 
>> Alex
> 
> Thanks
> Qi

Regards,
Keith