DPDK-dev Archive on lore.kernel.org
 help / color / Atom feed
From: Matan Azrad <matan@mellanox.com>
To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	Adrien Mazarguil <adrien.mazarguil@6wind.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] [RFC] ethdev: support flow aging
Date: Thu, 6 Jun 2019 10:51:30 +0000
Message-ID: <AM0PR0502MB4019412C41F481EAF2126BE1D2170@AM0PR0502MB4019.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <BYAPR18MB2424DD67DA45771C5DEC1FF5C8170@BYAPR18MB2424.namprd18.prod.outlook.com>

Hi Jerin

From: Jerin Jacob 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Matan Azrad
> > Sent: Sunday, May 26, 2019 3:48 PM
> > To: Adrien Mazarguil <adrien.mazarguil@6wind.com>; dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH] [RFC] ethdev: support flow aging
> >
> > One of the reasons to destroy a flow is the fact that no packet
> > matches the flow for "timeout" time.
> > For example, when TCP\UDP sessions are suddenly closed.
> >
> > Currently, there is no any dpdk mechanism for flow aging and the
> > applications use there own ways to detect and destroy aged-out flows.
> >
> > This RFC introduces flow aging APIs to offload the flow aging task
> > from the application to the port.
> >
> > Design:
> > - A new rte_flow action: RTE_FLOW_ACTION_TYPE_AGE to set the timeout
> > and
> >   the application flow context for each flow.
> > - A new ethdev event: RTE_ETH_EVENT_FLOW_AGED for the driver to
> report
> >   that there are new aged-out flows.
> > - A new rte_flow API: rte_flow_get_aged_flows to get the aged-out flows
> >   contexts from the port.
> >
> > By this design each PMD can use its best way to do the aging with the
> > device offloads supported by its HW.
> >
> > Signed-off-by: Matan Azrad <matan@mellanox.com>
> > ---
> >  lib/librte_ethdev/rte_ethdev.h |  1 +
> >  lib/librte_ethdev/rte_flow.h   | 56
> > ++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 57 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_ethdev.h
> > b/lib/librte_ethdev/rte_ethdev.h index 1f35e1d..6fc1531 100644
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -2771,6 +2771,7 @@ enum rte_eth_event_type {
> >  	RTE_ETH_EVENT_NEW,      /**< port is probed */
> >  	RTE_ETH_EVENT_DESTROY,  /**< port is released */
> >  	RTE_ETH_EVENT_IPSEC,    /**< IPsec offload related event */
> > +	RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows detected in
> > the port
> Does this event supported in HW?
It depends in the PMD implementation and HW capability.

> Or Are planning to implement with alarm
> or timer.
Again, depends in the PMD implementation.

> Just asking because, if none of the HW supports the interrupt then
> only rte_flow_get_aged_flows sync API be enough()
Why?

According to the above design this is the way for the PMD to notify the application when it has some aged flows ASAP.
So, if the PMD uses an alarm\timer or any other way to support aging action it is better in part of the cases to notify the user asynchronically instead of doing polling by the application.
The idea is to let the application to decide what is better for its usage.

For mlx5 case,
The plan is to raise this event from an HW interrupt handling(same as link event).

Matan. 
 








  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-26 10:18 Matan Azrad
2019-06-06 10:24 ` Jerin Jacob Kollanukkaran
2019-06-06 10:51   ` Matan Azrad [this message]
2019-06-06 12:15     ` Jerin Jacob Kollanukkaran
2019-06-18  5:56       ` Matan Azrad
2019-06-24  6:26         ` Jerin Jacob Kollanukkaran
2019-06-27  8:26           ` Matan Azrad

Reply instructions:

You may reply publically 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=AM0PR0502MB4019412C41F481EAF2126BE1D2170@AM0PR0502MB4019.eurprd05.prod.outlook.com \
    --to=matan@mellanox.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.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

DPDK-dev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dpdk-dev/0 dpdk-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dpdk-dev dpdk-dev/ https://lore.kernel.org/dpdk-dev \
		dev@dpdk.org dpdk-dev@archiver.kernel.org
	public-inbox-index dpdk-dev


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/ public-inbox