From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: "Wiles, Keith" <keith.wiles@intel.com>,
Alex Rosenbaum <rosenbaumalex@gmail.com>
Cc: "adrien.mazarguil@6wind.com" <adrien.mazarguil@6wind.com>,
DPDK <dev@dpdk.org>, "Doherty, Declan" <declan.doherty@intel.com>
Subject: Re: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support
Date: Sun, 14 Jan 2018 02:03:14 +0000 [thread overview]
Message-ID: <039ED4275CED7440929022BC67E706115312D465@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <F75B258F-F4F9-415C-AFF0-A806657EEDD9@intel.com>
Hi Alex & Keith
Base on my further understanding about OVS requirement and the new device's capability.
I realize there is no strong point to have the timeout APIs from this patch, I'd like to withdraw it.
Thanks for all your comments that help me to think it over.
Regards
Qi
> -----Original Message-----
> From: Wiles, Keith
> Sent: Friday, December 22, 2017 10:06 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Alex Rosenbaum <rosenbaumalex@gmail.com>;
> adrien.mazarguil@6wind.com; DPDK <dev@dpdk.org>; Doherty, Declan
> <declan.doherty@intel.com>
> Subject: Re: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support
>
>
>
> > On Dec 22, 2017, at 3:03 AM, Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
> >
> > Alex:
> >
> >> -----Original Message-----
> >> From: Alex Rosenbaum [mailto:rosenbaumalex@gmail.com]
> >> Sent: Thursday, December 21, 2017 9:59 PM
> >> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> >> Cc: adrien.mazarguil@6wind.com; DPDK <dev@dpdk.org>; Doherty, Declan
> >> <declan.doherty@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@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
next prev parent reply other threads:[~2018-01-14 2:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-21 2:35 [dpdk-dev] [RFC v2 0/5] rte_flow extension for vSwitch acceleration Qi Zhang
2017-12-21 2:35 ` [dpdk-dev] [RFC v2 1/5] ether: add flow action to redirect packet in a switch domain Qi Zhang
2017-12-21 12:37 ` Alex Rosenbaum
2017-12-22 8:20 ` Zhang, Qi Z
2017-12-22 22:10 ` Alex Rosenbaum
2017-12-21 2:35 ` [dpdk-dev] [RFC v2 2/5] ether: add flow last hit query support Qi Zhang
2017-12-21 2:35 ` [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support Qi Zhang
2017-12-21 13:59 ` Alex Rosenbaum
2017-12-22 9:03 ` Zhang, Qi Z
2017-12-22 14:06 ` Wiles, Keith
2018-01-14 2:03 ` Zhang, Qi Z [this message]
2017-12-22 22:26 ` Alex Rosenbaum
2017-12-26 3:28 ` Zhang, Qi Z
2017-12-26 7:44 ` Alex Rosenbaum
2017-12-21 2:35 ` [dpdk-dev] [RFC v2 4/5] ether: add more protocol support in rte_flow Qi Zhang
2017-12-21 2:35 ` [dpdk-dev] [RFC v2 5/5] ether: add packet modification aciton " Qi Zhang
2017-12-21 13:01 ` [dpdk-dev] [RFC v2 0/5] rte_flow extension for vSwitch acceleration Alex Rosenbaum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=039ED4275CED7440929022BC67E706115312D465@SHSMSX103.ccr.corp.intel.com \
--to=qi.z.zhang@intel.com \
--cc=adrien.mazarguil@6wind.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=keith.wiles@intel.com \
--cc=rosenbaumalex@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).