From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "Gaëtan Rivet" <gaetan.rivet@6wind.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
dev@dpdk.org, "Mcnamara, John" <john.mcnamara@intel.com>,
"Tahhan, Maryam" <maryam.tahhan@intel.com>
Subject: Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library
Date: Mon, 22 May 2017 11:13:23 +0200 [thread overview]
Message-ID: <20170522091323.GO1758@6wind.com> (raw)
In-Reply-To: <3128026.nHak02edMh@xps>
On Fri, May 19, 2017 at 12:11:53PM +0200, Thomas Monjalon wrote:
> 19/05/2017 11:11, Gaëtan Rivet:
> > On Fri, May 19, 2017 at 08:57:01AM +0000, Ananyev, Konstantin wrote:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > >> 18/05/2017 13:33, Ferruh Yigit:
> > >> > On 5/17/2017 5:38 PM, Gaëtan Rivet wrote:
> > >> > > The other is the expression of flows through a shared syntax. Using
> > >> > > flags to propose presets can be simpler, but will probably not be flexible
> > >> > > enough. rte_flow_items are a first-class citizen in DPDK and are
> > >> > > already a data type that can express flows with flexibility. As
> > >> > > mentioned, they are however missing a few elements to fully cover IPFIX
> > >> > > meters, but nothing that cannot be added I think.
> > >> > >
> > >> > > So I was probably not clear enough, but I was thinking about
> > >> > > supporting rte_flow_items in rte_flow_classify as the possible key
> > >> > > applications would use to configure their measurements. This should not
> > >> > > require rte_flow supports from the PMDs they would be using, only
> > >> > > rte_flow_item parsing from the rte_flow_classify library.
> > >> > >
> > >> > > Otherwise, DPDK will probably end up with two competing flow
> > >> > > representations. Additionally, it may be interesting for applications
> > >> > > to bind these data directly to rte_flow actions once the
> > >> > > classification has been analyzed.
> > >> >
> > >> > Thanks for clarification, I see now what you and Konstantin is proposing.
> > >> >
> > >> > And yes it makes sense to use rte_flow to define flows in the library, I
> > >> > will update the RFC.
> > >>
> > >> Does it mean that rte_flow.h must be moved from ethdev to this
> > >> new flow library? Or will it depend of ethdev?
> >
> > Even outside of lib/librte_ether, wouldn't rte_flow stay dependent on
> > rte_ether?
> >
> > >
> > >Just a thought: probably move rte_flow.h to lib/librte_net?
> > >Konstantin
> >
> > If we are to move rte_flow, why not lib/librte_flow?
>
> There are 3 different things:
> 1/ rte_flow.h for flow description
> 2/ rte_flow API in ethdev for HW offloading
> 3/ SW flow table (this new lib)
>
> 2 and 3 will depends on 1.
> I think moving rte_flow.h in librte_net is a good idea.
If I had to choose, it would be librte_flow over librte_net because rte_flow
is not necessarily about matching protocol headers (e.g. you can can match
meta properties like physical ports or the fact traffic comes from a
specific VF).
However, I am not sure a separate library is actually necessary, I think the
requirements can be addressed by rte_flow (in its current directory)
directly.
One assumption is that the COUNT action as currently described by rte_flow
satisfies the counters requirements from this proposal, new actions could be
added later to return other flow-related properties. In short there is no
need to return info from individual packets, only from the flows themselves.
If the above is true, then as pointed earlier by Gaetan this proposal can be
summarized as a software implementation for rte_flow_query() and related
actions.
To determine if a packet is part of a given flow in software and update the
associated flow counters, it must be parsed and compared against patterns of
all existing rte_flow rules until one of them matches. For accurate results,
this must be done on all TX/RX traffic.
RFCv1 does so by automatically hooking burst functions while RFCv2 does so
by expecting the application to call rte_flow_classify_stats_get().
One issue I would like to raise before going on is the CPU cost of doing all
this. Parsing all incoming/outgoing traffic without missing any, looking up
related flows and updating counters in software seems like a performance
killer. Applications will likely request assistance from HW to minimize this
cost as much as possible (e.g. using the rte_flow MARK action if COUNT is
not supported directly).
Assuming a flow is identified by HW, parsing it once again in software with
the proposed API to update the related stats seems counterproductive; a
hybrid HW/SW solution with the SW part automatically used as a fallback when
hardware is not capable enough would be better and easier to use.
The topic of software fallbacks for rte_flow was brought up some time ago
(can't find the exact thread). The intent was to expose a common set of
features between PMDs so that applications do not have to implement their
own fallbacks. They would request it on a rule basis by setting a kind of
"sw_fallback" bit in flow rule attributes (struct rte_flow_attr). This bit
would be checked by PMDs and/or the rte_flow_* wrapper functions after the
underlying PMD refuses to validate/create a rule.
Basically I think rte_flow_classify could be entirely implemented in
rte_flow through this "sw_fallback" approach in order for applications to
automatically benefit from HW acceleration when PMDs can handle it. It then
makes sense for the underlying implementation to use RX/TX hooks if
necessary (as in RFCv1). These hooks would be removed by destroying the
related flow rule(s).
This would also open the door to a full SW implementation for rte_flow given
that once the packet parser is there, most actions can be implemented rather
easily (well, that's still a lot of work.)
Bottom line is I'm not against a separate SW implementation not tied to a
port_id for rte_flow_classify, but I would like to hear the community's
thoughts about the above first.
--
Adrien Mazarguil
6WIND
next prev parent reply other threads:[~2017-05-22 9:13 UTC|newest]
Thread overview: 145+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 18:54 [dpdk-dev] [RFC 17.08] Flow classification library Ferruh Yigit
2017-04-20 18:54 ` [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library Ferruh Yigit
2017-05-04 11:35 ` Mcnamara, John
2017-05-16 22:19 ` Thomas Monjalon
2017-05-17 14:54 ` Ananyev, Konstantin
2017-05-17 15:37 ` Ferruh Yigit
2017-05-17 16:10 ` Ananyev, Konstantin
2017-05-18 12:12 ` Ferruh Yigit
2017-05-17 16:02 ` Ferruh Yigit
2017-05-17 16:18 ` Ananyev, Konstantin
2017-05-17 16:38 ` Gaëtan Rivet
2017-05-18 11:33 ` Ferruh Yigit
2017-05-18 20:31 ` Thomas Monjalon
2017-05-19 8:57 ` Ananyev, Konstantin
2017-05-19 9:11 ` Gaëtan Rivet
2017-05-19 9:40 ` Ananyev, Konstantin
2017-05-19 10:11 ` Thomas Monjalon
2017-05-22 9:13 ` Adrien Mazarguil [this message]
2017-04-21 10:38 ` [dpdk-dev] [RFC 17.08] Flow classification library Gaëtan Rivet
2017-05-03 9:15 ` Mcnamara, John
2017-05-06 14:04 ` Morten Brørup
2017-05-09 13:37 ` Ferruh Yigit
2017-05-09 19:24 ` Morten Brørup
2017-05-17 11:26 ` Ferruh Yigit
2017-05-09 13:26 ` Ferruh Yigit
2017-05-18 18:12 ` [dpdk-dev] [RFC v2] " Ferruh Yigit
2017-05-18 18:12 ` [dpdk-dev] [RFC v2] flow_classify: add librte_flow_classify library Ferruh Yigit
2017-05-19 16:30 ` [dpdk-dev] [RFC v2] Flow classification library Iremonger, Bernard
2017-05-22 13:53 ` Ferruh Yigit
2017-05-23 12:26 ` Adrien Mazarguil
2017-05-23 12:58 ` Ferruh Yigit
2017-05-23 13:30 ` Adrien Mazarguil
2017-05-23 16:42 ` Ferruh Yigit
2017-05-25 15:46 ` [dpdk-dev] [RFC v3] " Ferruh Yigit
2017-05-25 15:46 ` [dpdk-dev] [RFC v3] flow_classify: add librte_flow_classify library Ferruh Yigit
2017-05-30 12:59 ` Iremonger, Bernard
2017-08-23 13:51 ` [dpdk-dev] [PATCH v1 0/6] Flow classification library Bernard Iremonger
2017-08-25 16:10 ` [dpdk-dev] [PATCH v2 0/6] flow " Bernard Iremonger
2017-08-31 14:54 ` [dpdk-dev] [PATCH v3 0/5] " Bernard Iremonger
2017-09-06 10:27 ` [dpdk-dev] [PATCH v4 " Bernard Iremonger
2017-09-07 16:43 ` [dpdk-dev] [PATCH v5 0/6] " Bernard Iremonger
2017-09-29 9:18 ` [dpdk-dev] [PATCH v6 0/4] " Bernard Iremonger
2017-10-02 9:31 ` [dpdk-dev] [PATCH v7 " Bernard Iremonger
2017-10-17 20:26 ` [dpdk-dev] [PATCH v8 " Bernard Iremonger
2017-10-22 13:32 ` [dpdk-dev] [PATCH v9 " Bernard Iremonger
2017-10-23 15:16 ` [dpdk-dev] [PATCH v10 " Bernard Iremonger
2017-10-23 20:59 ` Thomas Monjalon
2017-10-24 8:40 ` Iremonger, Bernard
2017-10-24 9:23 ` Mcnamara, John
2017-10-24 9:38 ` Thomas Monjalon
2017-10-24 9:53 ` Iremonger, Bernard
2017-10-24 10:25 ` Thomas Monjalon
2017-10-24 17:27 ` [dpdk-dev] [PATCH v11 " Bernard Iremonger
2017-10-24 20:33 ` Thomas Monjalon
2017-10-25 8:47 ` Iremonger, Bernard
2017-10-25 8:56 ` Thomas Monjalon
2017-10-24 17:28 ` [dpdk-dev] [PATCH v11 1/4] flow_classify: add flow classify library Bernard Iremonger
2017-10-24 19:39 ` Thomas Monjalon
2017-10-25 11:10 ` Iremonger, Bernard
2017-10-25 12:13 ` Thomas Monjalon
2017-10-24 19:41 ` Thomas Monjalon
2017-10-24 19:43 ` Thomas Monjalon
2017-10-24 20:05 ` Thomas Monjalon
2017-10-24 20:16 ` Thomas Monjalon
2017-10-24 20:18 ` Thomas Monjalon
2017-10-24 17:28 ` [dpdk-dev] [PATCH v11 2/4] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-10-24 20:13 ` Thomas Monjalon
2017-10-24 17:28 ` [dpdk-dev] [PATCH v11 3/4] test: add packet burst generator functions Bernard Iremonger
2017-10-24 17:28 ` [dpdk-dev] [PATCH v11 4/4] test: flow classify library unit tests Bernard Iremonger
2017-10-23 15:16 ` [dpdk-dev] [PATCH v10 1/4] librte_flow_classify: add flow classify library Bernard Iremonger
2017-10-23 16:03 ` Singh, Jasvinder
2017-10-24 9:50 ` Thomas Monjalon
2017-10-24 10:09 ` Iremonger, Bernard
2017-10-23 15:16 ` [dpdk-dev] [PATCH v10 2/4] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-10-23 16:04 ` Singh, Jasvinder
2017-10-23 15:16 ` [dpdk-dev] [PATCH v10 3/4] test: add packet burst generator functions Bernard Iremonger
2017-10-23 16:05 ` Singh, Jasvinder
2017-10-23 15:16 ` [dpdk-dev] [PATCH v10 4/4] test: flow classify library unit tests Bernard Iremonger
2017-10-23 16:06 ` Singh, Jasvinder
2017-10-22 13:32 ` [dpdk-dev] [PATCH v9 1/4] librte_flow_classify: add flow classify library Bernard Iremonger
2017-10-23 13:21 ` Singh, Jasvinder
2017-10-23 13:37 ` Iremonger, Bernard
2017-10-22 13:32 ` [dpdk-dev] [PATCH v9 2/4] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-10-22 13:32 ` [dpdk-dev] [PATCH v9 3/4] test: add packet burst generator functions Bernard Iremonger
2017-10-22 13:32 ` [dpdk-dev] [PATCH v9 4/4] test: flow classify library unit tests Bernard Iremonger
2017-10-17 20:26 ` [dpdk-dev] [PATCH v8 1/4] librte_flow_classify: add flow classify library Bernard Iremonger
2017-10-19 14:22 ` Singh, Jasvinder
2017-10-20 16:59 ` Iremonger, Bernard
2017-10-21 12:07 ` Iremonger, Bernard
2017-10-17 20:26 ` [dpdk-dev] [PATCH v8 2/4] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-10-17 20:26 ` [dpdk-dev] [PATCH v8 3/4] test: add packet burst generator functions Bernard Iremonger
2017-10-17 20:26 ` [dpdk-dev] [PATCH v8 4/4] test: flow classify library unit tests Bernard Iremonger
2017-10-02 9:31 ` [dpdk-dev] [PATCH v7 1/4] librte_flow_classify: add librte_flow_classify library Bernard Iremonger
2017-10-06 15:00 ` Singh, Jasvinder
2017-10-09 9:28 ` Mcnamara, John
2017-10-13 15:39 ` Iremonger, Bernard
2017-10-02 9:31 ` [dpdk-dev] [PATCH v7 2/4] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-10-02 9:31 ` [dpdk-dev] [PATCH v7 3/4] test: add packet burst generator functions Bernard Iremonger
2017-10-02 9:31 ` [dpdk-dev] [PATCH v7 4/4] test: flow classify library unit tests Bernard Iremonger
2017-09-29 9:18 ` [dpdk-dev] [PATCH v6 1/4] librte_flow_classify: add librte_flow_classify library Bernard Iremonger
2017-09-29 9:18 ` [dpdk-dev] [PATCH v6 2/4] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-09-29 9:18 ` [dpdk-dev] [PATCH v6 3/4] test: add packet burst generator functions Bernard Iremonger
2017-09-29 9:18 ` [dpdk-dev] [PATCH v6 4/4] test: flow classify library unit tests Bernard Iremonger
2017-09-07 16:43 ` [dpdk-dev] [PATCH v5 1/6] librte_table: fix acl entry add and delete functions Bernard Iremonger
2017-09-18 15:29 ` Singh, Jasvinder
2017-09-20 12:21 ` Dumitrescu, Cristian
2017-09-29 8:25 ` Iremonger, Bernard
2017-09-07 16:43 ` [dpdk-dev] [PATCH v5 2/6] librte_table: fix acl lookup function Bernard Iremonger
2017-09-20 12:24 ` Dumitrescu, Cristian
2017-09-29 8:27 ` Iremonger, Bernard
2017-09-07 16:43 ` [dpdk-dev] [PATCH v5 3/6] librte_flow_classify: add librte_flow_classify library Bernard Iremonger
2017-09-07 16:43 ` [dpdk-dev] [PATCH v5 4/6] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-09-07 16:43 ` [dpdk-dev] [PATCH v5 5/6] test: add packet burst generator functions Bernard Iremonger
2017-09-07 16:43 ` [dpdk-dev] [PATCH v5 6/6] test: flow classify library unit tests Bernard Iremonger
2017-09-06 10:27 ` [dpdk-dev] [PATCH v4 1/5] librte_table: fix acl entry add and delete functions Bernard Iremonger
2017-09-06 10:27 ` [dpdk-dev] [PATCH v4 2/5] librte_table: fix acl lookup function Bernard Iremonger
2017-09-06 10:27 ` [dpdk-dev] [PATCH v4 3/5] librte_flow_classify: add librte_flow_classify library Bernard Iremonger
2017-09-06 10:27 ` [dpdk-dev] [PATCH v4 4/5] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-09-06 10:27 ` [dpdk-dev] [PATCH v4 5/5] test: flow classify library unit tests Bernard Iremonger
2017-08-31 14:54 ` [dpdk-dev] [PATCH v3 1/5] librte_table: fix acl entry add and delete functions Bernard Iremonger
2017-08-31 15:09 ` Pavan Nikhilesh Bhagavatula
2017-08-31 14:54 ` [dpdk-dev] [PATCH v3 2/5] librte_table: fix acl lookup function Bernard Iremonger
2017-08-31 14:54 ` [dpdk-dev] [PATCH v3 3/5] librte_flow_classify: add librte_flow_classify library Bernard Iremonger
2017-08-31 15:18 ` Pavan Nikhilesh Bhagavatula
2017-08-31 14:54 ` [dpdk-dev] [PATCH v3 4/5] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-08-31 14:54 ` [dpdk-dev] [PATCH v3 5/5] test: flow classify library unit tests Bernard Iremonger
2017-08-25 16:10 ` [dpdk-dev] [PATCH v2 1/6] librte_table: fix acl entry add and delete functions Bernard Iremonger
2017-08-25 16:10 ` [dpdk-dev] [PATCH v2 2/6] librte_table: fix acl lookup function Bernard Iremonger
2017-08-25 16:10 ` [dpdk-dev] [PATCH v2 3/6] librte_ether: initialise IPv4 protocol mask for rte_flow Bernard Iremonger
2017-08-30 12:39 ` Adrien Mazarguil
2017-08-30 13:28 ` Iremonger, Bernard
2017-08-30 14:39 ` Adrien Mazarguil
2017-08-30 15:12 ` Iremonger, Bernard
2017-08-25 16:10 ` [dpdk-dev] [PATCH v2 4/6] librte_flow_classify: add librte_flow_classify library Bernard Iremonger
2017-08-25 16:10 ` [dpdk-dev] [PATCH v2 5/6] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-08-25 16:10 ` [dpdk-dev] [PATCH v2 6/6] test: flow classify library unit tests Bernard Iremonger
2017-08-23 13:51 ` [dpdk-dev] [PATCH v1 1/6] librte_table: move structure to header file Bernard Iremonger
2017-08-23 14:13 ` Dumitrescu, Cristian
2017-08-23 14:32 ` Iremonger, Bernard
2017-08-28 8:48 ` Iremonger, Bernard
2017-08-23 13:51 ` [dpdk-dev] [PATCH v1 2/6] librte_table: fix acl entry add and delete functions Bernard Iremonger
2017-08-23 13:51 ` [dpdk-dev] [PATCH v1 3/6] librte_ether: initialise IPv4 protocol mask for rte_flow Bernard Iremonger
2017-08-23 13:51 ` [dpdk-dev] [PATCH v1 4/6] librte_flow_classify: add librte_flow_classify library Bernard Iremonger
2017-08-23 13:51 ` [dpdk-dev] [PATCH v1 5/6] examples/flow_classify: flow classify sample application Bernard Iremonger
2017-08-23 13:51 ` [dpdk-dev] [PATCH v1 6/6] test: flow classify library unit tests Bernard Iremonger
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=20170522091323.GO1758@6wind.com \
--to=adrien.mazarguil@6wind.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=gaetan.rivet@6wind.com \
--cc=john.mcnamara@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=maryam.tahhan@intel.com \
--cc=thomas@monjalon.net \
/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).