From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: Alex Rosenbaum <rosenbaumalex@gmail.com>
Cc: "adrien.mazarguil@6wind.com" <adrien.mazarguil@6wind.com>,
DPDK <dev@dpdk.org>, "Doherty, Declan" <declan.doherty@intel.com>,
"Chandran, Sugesh" <sugesh.chandran@intel.com>
Subject: Re: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support
Date: Tue, 26 Dec 2017 03:28:40 +0000 [thread overview]
Message-ID: <039ED4275CED7440929022BC67E7061153125026@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <CAFgAxU_xig-ZUfmHpz4sFdsbk6c1wP3CBX2YTVAFgcDw_R8s3A@mail.gmail.com>
Hi Alex:
> -----Original Message-----
> From: Alex Rosenbaum [mailto:rosenbaumalex@gmail.com]
> Sent: Saturday, December 23, 2017 6:27 AM
> 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 Fri, Dec 22, 2017 at 11:03 AM, Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
> >> 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 sure this will allow OVS to 'fire-and-forget' about the rule removal?
> or will OVS anyway do rule cleanup from application tables?
There is some framework design about offload flow management on OVS side.
Since I'm not a OVS guy, I can't answer OVS specific question precisely right now,
but the feedback I got is, it will be nice if rte_flow could support flow timeout
I may check with some OVS expert to give further explanation.
BTW, I think there is no harmful to add these APIs into rte_flow, since a flow timeout is quite
generic feature to me. it may be useful even for non-OVS case in future.
>
> 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?
As I know, for OVS every flow just has a fixed time duration, so "hard_timeout"
is going for this requirement, but by following OpenFlow spec, idle_timeout is paired
with hard_timeout so I just add it since its generic and maybe useful for future.
>
>
> >> 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.
Usually the flow auto delete is running on a separate background thread
(an interrupt handler or a watchdog thread base on hardware capability)
The low level driver is responsible to take care of the race condition between background and foreground flow deleting.
For application, it should be aware that the callback function is running on a separate thread, so it is also required to
take care of race condition if it will access some data that is shared by foreground thread.
>
> Alex
Regards
Qi
next prev parent reply other threads:[~2017-12-26 3:28 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
2017-12-22 22:26 ` Alex Rosenbaum
2017-12-26 3:28 ` Zhang, Qi Z [this message]
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=039ED4275CED7440929022BC67E7061153125026@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=rosenbaumalex@gmail.com \
--cc=sugesh.chandran@intel.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).