From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Thomas Monjalon <thomas.monjalon@6wind.com>,
"Zhang, Helin" <helin.zhang@intel.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
Rasesh Mody <rasesh.mody@qlogic.com>,
Ajit Khaparde <ajit.khaparde@broadcom.com>,
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>,
Jan Medala <jan@semihalf.com>, John Daley <johndale@cisco.com>,
"Chen, Jing D" <jing.d.chen@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
Matej Vido <matejvido@gmail.com>,
Alejandro Lucero <alejandro.lucero@netronome.com>,
Sony Chacko <sony.chacko@qlogic.com>,
Jerin Jacob <jerin.jacob@caviumnetworks.com>,
"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
Olga Shern <olgas@mellanox.com>
Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification API
Date: Thu, 7 Jul 2016 12:26:50 +0200 [thread overview]
Message-ID: <20160707102650.GU7621@6wind.com> (raw)
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09090348E1A7@shsmsx102.ccr.corp.intel.com>
Hi Lu Wenzhuo,
Thanks for your feedback, I'm replying below as well.
On Thu, Jul 07, 2016 at 07:14:18AM +0000, Lu, Wenzhuo wrote:
> Hi Adrien,
> I have some questions, please see inline, thanks.
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Wednesday, July 6, 2016 2:17 AM
> > To: dev@dpdk.org
> > Cc: Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody; Ajit Khaparde;
> > Rahul Lakkireddy; Lu, Wenzhuo; Jan Medala; John Daley; Chen, Jing D; Ananyev,
> > Konstantin; Matej Vido; Alejandro Lucero; Sony Chacko; Jerin Jacob; De Lara
> > Guarch, Pablo; Olga Shern
> > Subject: [RFC] Generic flow director/filtering/classification API
> >
> >
> > Requirements for a new API:
> >
> > - Flexible and extensible without causing API/ABI problems for existing
> > applications.
> > - Should be unambiguous and easy to use.
> > - Support existing filtering features and actions listed in `Filter types`_.
> > - Support packet alteration.
> > - In case of overlapping filters, their priority should be well documented.
> Does that mean we don't guarantee the consistent of priority? The priority can be different on different NICs. So the behavior of the actions can be different. Right?
No, the intent is precisely to define what happens in order to get a
consistent result across different devices, and document cases with
undefined behavior. There must be no room left for interpretation.
For example, the API must describe what happens when two overlapping filters
(e.g. one matching an Ethernet header, another one matching an IP header)
match a given packet at a given priority level.
It is documented in section 4.1.1 (priorities) as "undefined behavior".
Applications remain free to do it and deal with consequences, at least they
know they cannot expect a consistent outcome, unless they use different
priority levels for both rules, see also 4.4.5 (flow rules priority).
> Seems the users still need to aware the some details of the HW? Do we need to add the negotiation for the priority?
Priorities as defined in this document may not be directly mappable to HW
capabilities (e.g. HW does not support enough priorities, or that some
corner case make them not work as described), in which case the PMD may
choose to simulate priorities (again 4.4.5), as long as the end result
follows the specification.
So users must not be aware of some HW details, the PMD does and must perform
the needed workarounds to suit their expectations. Users may only be
impacted by errors while attempting to create rules that are either
unsupported or would cause them (or existing rules) to diverge from the
spec.
> > Flow rules can have several distinct actions (such as counting,
> > encapsulating, decapsulating before redirecting packets to a particular
> > queue, etc.), instead of relying on several rules to achieve this and having
> > applications deal with hardware implementation details regarding their
> > order.
> I think normally HW doesn't support several actions in one rule. If a rule has several actions, seems HW has to split it to several rules. The order can still be a problem.
Note that, except for a very small subset of pattern items and actions,
supporting multiple actions for a given rule is not mandatory, and can be
emulated as you said by having to split them into several rules each with
its own priority if possible (see 3.3 "high level design").
Also, a rule "action" as defined in this API can be just about anything, for
example combining a queue redirection with 32-bit tagging. FDIR supports
many cases of what can be described as several actions, see 5.7 "FDIR to
most item types → QUEUE, DROP, PASSTHRU".
If you were thinking about having two queue targets for a given rule, then
I agree with you - that is why a rule cannot have more than a single action
of a given type (see 4.1.5 actions), to avoid such abuse from applications.
Applications must use several pass-through rules with different priority
levels if they want to perform a given action several times on a given
packet. Again, PMDs support is not mandatory as pass-through is optional.
> > ``ETH``
> > ^^^^^^^
> >
> > Matches an Ethernet header.
> >
> > - ``dst``: destination MAC.
> > - ``src``: source MAC.
> > - ``type``: EtherType.
> > - ``tags``: number of 802.1Q/ad tags defined.
> > - ``tag[]``: 802.1Q/ad tag definitions, innermost first. For each one:
> >
> > - ``tpid``: Tag protocol identifier.
> > - ``tci``: Tag control information.
> "ETH" means all the parameters, dst, src, type... need to be matched? The same question for IPv4, IPv6 ...
Yes, it's basically the description of all Ethernet header fields including
VLAN tags (same for other protocols). Please see the linked draft header
file which should make all of this easier to understand:
https://raw.githubusercontent.com/6WIND/rte_flow/master/rte_flow.h
> > ``UDP``
> > ^^^^^^^
> >
> > Matches a UDP header.
> >
> > - ``sport``: source port.
> > - ``dport``: destination port.
> > - ``length``: UDP length.
> > - ``checksum``: UDP checksum.
> Why checksum? Do we need to filter the packets by checksum value?
Well, I've decided to include all protocol header fields for completeness
(so the ABI does not need to be broken later then they become necessary, or
require another pattern item), not that all of them make sense in a pattern.
In this specific case, all PMDs I know of must reject a pattern
specification with a nonzero mask for the checksum field, because none of
them support it.
> > ``VOID`` (action)
> > ^^^^^^^^^^^^^^^^^
> >
> > Used as a placeholder for convenience. It is ignored and simply discarded by
> > PMDs.
> Don't understand why we need VOID. If it’s about the format. Why not guarantee it in rte layer?
I'm not sure to understand your question about rte layer, but this type is
fully managed by the PMD and is not supposed to be translated to a hardware
action.
I think it may come handy in some cases (like the VOID pattern item), so it
is defined just in case. Should be relatively trivial to support.
Applications may find a use for it when they want to statically define
templates for flow rules, when they need room for some reason.
> > Behavior
> > --------
> >
> > - API operations are synchronous and blocking (``EAGAIN`` cannot be
> > returned).
> >
> > - There is no provision for reentrancy/multi-thread safety, although nothing
> > should prevent different devices from being configured at the same
> > time. PMDs may protect their control path functions accordingly.
> >
> > - Stopping the data path (TX/RX) should not be necessary when managing flow
> > rules. If this cannot be achieved naturally or with workarounds (such as
> > temporarily replacing the burst function pointers), an appropriate error
> > code must be returned (``EBUSY``).
> PMD cannot stop the data path without adding lock. So I think if some rules cannot be applied without stopping rx/tx, PMD has to return fail.
> Or let the APP to stop the data path.
Agreed, that is the intent. If the PMD cannot touch flow rules for some
reason even after trying really hard, then it just returns EBUSY.
Perhaps we should write down that applications may get a different outcome
after stopping the data path if they get EBUSY?
> > - PMDs, not applications, are responsible for maintaining flow rules
> > configuration when stopping and restarting a port or performing other
> > actions which may affect them. They can only be destroyed explicitly.
> Don’t understand " They can only be destroyed explicitly."
This part says that as long as an application has not called
rte_flow_destroy() on a flow rule, it never disappears, whatever happens to
the port (stopped, restarted). The application is not responsible for
re-creating rules after that.
Note that according to the specification, this may translate to not being
able to stop a port as long as a flow rule is present, depending on how nice
the PMD intends to be with applications. Implementation can be done in small
steps with minimal amount of code on the PMD side.
> If a new rule has conflict with an old one, what should we do? Return fail?
That should not happen. If say 100 rules have been created with various
priorities and the port is happily running with them, stopping the port may
require the PMD to destroy them, it then has to re-create all 100 of them
exactly as they were automatically when restarting the port.
If re-creating them is not possible for some reason, the port cannot be
restarted as long as rules that cannot be added back haven't been destroyed
by the application. Frankly, this should not happen.
To manage this case, I suggest preventing applications from doing things
that conflict with existing flow rules while the port is stopped (just like
when it is not stopped, as described in 5.7 "FDIR to most item types").
> > ``ANY`` pattern item
> > ~~~~~~~~~~~~~~~~~~~~
> >
> > This pattern item stands for anything, which can be difficult to translate
> > to something hardware would understand, particularly if followed by more
> > specific types.
> >
> > Consider the following pattern:
> >
> > +---+--------------------------------+
> > | 0 | ETHER |
> > +---+--------------------------------+
> > | 1 | ANY (``min`` = 1, ``max`` = 1) |
> > +---+--------------------------------+
> > | 2 | TCP |
> > +---+--------------------------------+
> >
> > Knowing that TCP does not make sense with something other than IPv4 and IPv6
> > as L3, such a pattern may be translated to two flow rules instead:
> >
> > +---+--------------------+
> > | 0 | ETHER |
> > +---+--------------------+
> > | 1 | IPV4 (zeroed mask) |
> > +---+--------------------+
> > | 2 | TCP |
> > +---+--------------------+
> >
> > +---+--------------------+
> > | 0 | ETHER |
> > +---+--------------------+
> > | 1 | IPV6 (zeroed mask) |
> > +---+--------------------+
> > | 2 | TCP |
> > +---+--------------------+
> >
> > Note that as soon as a ANY rule covers several layers, this approach may
> > yield a large number of hidden flow rules. It is thus suggested to only
> > support the most common scenarios (anything as L2 and/or L3).
> I think "any" may make things confusing. How about if the NIC doesn't support IPv6? Should we return fail for this rule?
In a sense you are right, ANY relies on HW capabilities so you cannot know
that it won't match unsupported protocols. The above example would be
somewhat useless for a conscious application which should really have
created two separate flow rules (and gotten an error on the IPv6 one).
So an ANY flow rule only able to match v4 packets won't return an error.
ANY can be useful to match outer packets when only a tunnel header and the
inner packet are meaningful to the application. HW that does not recognize
the outer packet is not able to recognize the inner one anyway.
This section only says that PMDs should do their best to make HW match what
they can when faced with ANY.
Also once again, ANY support is not mandatory.
> > Flow rules priority
> > ~~~~~~~~~~~~~~~~~~~
> >
> > While it would naturally make sense, flow rules cannot be assumed to be
> > processed by hardware in the same order as their creation for several
> > reasons:
> >
> > - They may be managed internally as a tree or a hash table instead of a
> > list.
> > - Removing a flow rule before adding another one can either put the new rule
> > at the end of the list or reuse a freed entry.
> > - Duplication may occur when packets are matched by several rules.
> >
> > For overlapping rules (particularly in order to use the `PASSTHRU`_ action)
> > predictable behavior is only guaranteed by using different priority levels.
> >
> > Priority levels are not necessarily implemented in hardware, or may be
> > severely limited (e.g. a single priority bit).
> >
> > For these reasons, priority levels may be implemented purely in software by
> > PMDs.
> >
> > - For devices expecting flow rules to be added in the correct order, PMDs
> > may destroy and re-create existing rules after adding a new one with
> > a higher priority.
> >
> > - A configurable number of dummy or empty rules can be created at
> > initialization time to save high priority slots for later.
> >
> > - In order to save priority levels, PMDs may evaluate whether rules are
> > likely to collide and adjust their priority accordingly.
> If there's 3 rules, r1, r2,r3. The rules say the priority is r1 > r2 > r3. If PMD can only support r1 > r3 > r2, or doesn't support r2. Should PMD apply r1 and r3 or totally not support them all?
Remember that the API lets applications create only one rule at a time. If
all 3 rules are not supported together but individually are, the answer
depends on what the application does:
1. r1 OK, r2 FAIL => application chooses to stop here, thus only r1 works as
expected (may roll back and remove r1 as a result).
2. r1 OK, r2 FAIL, r3 OK => application chooses to ignore the fact r2 failed
and added r3 anyway, so it should end up with r1 > r3.
Applications should do as described in 1, they need to check for errors if
they want consistency.
This document describes only the basic functions, but may be extended later
with methods to add several flow rules at once, so rules that depend on
others can be added together and a single failure is returned without the
need for a rollback at the application level.
> A generic question, is the parsing supposed to be done by rte or PMD?
Actually, a bit of both. EAL will certainly at least provide helpers to
assist PMDs. This specification defines only the public-facing API for now,
but our goal is really to have something that is not too difficult to
implement both for applications and PMDs.
These helpers can be defined later with the first implementation.
--
Adrien Mazarguil
6WIND
next prev parent reply other threads:[~2016-07-07 10:26 UTC|newest]
Thread overview: 262+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-05 18:16 Adrien Mazarguil
2016-07-07 7:14 ` Lu, Wenzhuo
2016-07-07 10:26 ` Adrien Mazarguil [this message]
2016-07-19 8:11 ` Lu, Wenzhuo
2016-07-19 13:12 ` Adrien Mazarguil
2016-07-20 2:16 ` Lu, Wenzhuo
2016-07-20 10:41 ` Adrien Mazarguil
2016-07-21 3:18 ` Lu, Wenzhuo
2016-07-21 12:47 ` Adrien Mazarguil
2016-07-22 1:38 ` Lu, Wenzhuo
2016-07-07 23:15 ` Chandran, Sugesh
2016-07-08 13:03 ` Adrien Mazarguil
2016-07-11 10:42 ` Chandran, Sugesh
2016-07-13 20:03 ` Adrien Mazarguil
2016-07-15 9:23 ` Chandran, Sugesh
2016-07-15 10:02 ` Chilikin, Andrey
2016-07-18 13:26 ` Chandran, Sugesh
2016-07-15 15:04 ` Adrien Mazarguil
2016-07-18 13:26 ` Chandran, Sugesh
2016-07-18 15:00 ` Adrien Mazarguil
2016-07-20 16:32 ` Chandran, Sugesh
2016-07-20 17:10 ` Adrien Mazarguil
2016-07-21 11:06 ` Chandran, Sugesh
2016-07-21 13:37 ` Adrien Mazarguil
2016-07-22 16:32 ` Chandran, Sugesh
2016-07-08 11:11 ` Liang, Cunming
2016-07-08 12:38 ` Bruce Richardson
2016-07-08 13:25 ` Adrien Mazarguil
2016-07-11 3:18 ` Liang, Cunming
2016-07-11 10:06 ` Adrien Mazarguil
2016-07-11 10:41 ` Jerin Jacob
2016-07-21 19:20 ` Adrien Mazarguil
2016-07-23 21:10 ` John Fastabend
2016-08-02 18:19 ` John Fastabend
2016-08-03 14:30 ` Adrien Mazarguil
2016-08-03 18:10 ` John Fastabend
2016-08-04 13:05 ` Adrien Mazarguil
2016-08-09 21:24 ` John Fastabend
2016-08-10 11:02 ` Adrien Mazarguil
2016-08-10 16:35 ` John Fastabend
2016-07-21 8:13 ` Rahul Lakkireddy
2016-07-21 17:07 ` Adrien Mazarguil
2016-07-25 11:32 ` Rahul Lakkireddy
2016-07-25 16:40 ` John Fastabend
2016-07-26 10:07 ` Rahul Lakkireddy
2016-08-03 16:44 ` Adrien Mazarguil
2016-08-03 19:11 ` John Fastabend
2016-08-04 13:24 ` Adrien Mazarguil
2016-08-09 21:47 ` John Fastabend
2016-08-10 13:37 ` Adrien Mazarguil
2016-08-10 16:46 ` John Fastabend
2016-08-19 21:13 ` John Daley (johndale)
2016-08-19 19:32 ` [dpdk-dev] [RFC v2] " Adrien Mazarguil
2016-08-19 19:32 ` [dpdk-dev] [RFC v2] ethdev: introduce generic flow API Adrien Mazarguil
2016-08-20 7:00 ` Lu, Wenzhuo
2016-08-22 18:20 ` John Fastabend
2016-08-22 18:30 ` [dpdk-dev] [RFC v2] Generic flow director/filtering/classification API John Fastabend
2016-09-29 17:10 ` Adrien Mazarguil
2016-10-31 7:19 ` Zhang, Helin
2016-11-02 11:13 ` Adrien Mazarguil
2016-11-08 1:31 ` Zhang, Helin
2016-11-09 11:07 ` Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow) Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API Adrien Mazarguil
2016-11-18 6:36 ` Xing, Beilei
2016-11-18 10:28 ` Adrien Mazarguil
2016-11-30 17:47 ` Kevin Traynor
2016-12-01 8:36 ` Adrien Mazarguil
2016-12-02 21:06 ` Kevin Traynor
2016-12-06 18:11 ` Chandran, Sugesh
2016-12-08 15:09 ` Adrien Mazarguil
2016-12-09 12:18 ` Chandran, Sugesh
2016-12-09 16:38 ` Adrien Mazarguil
2016-12-12 10:20 ` Chandran, Sugesh
2016-12-12 11:17 ` Adrien Mazarguil
2016-12-08 17:07 ` Adrien Mazarguil
2016-12-14 11:48 ` Kevin Traynor
2016-12-14 13:54 ` Adrien Mazarguil
2016-12-14 16:11 ` Kevin Traynor
2016-12-08 9:00 ` Xing, Beilei
2016-12-08 14:50 ` Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 02/22] cmdline: add support for dynamic tokens Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 03/22] cmdline: add alignment constraint Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 04/22] app/testpmd: implement basic support for rte_flow Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 05/22] app/testpmd: add flow command Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 06/22] app/testpmd: add rte_flow integer support Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 07/22] app/testpmd: add flow list command Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 08/22] app/testpmd: add flow flush command Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 09/22] app/testpmd: add flow destroy command Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 10/22] app/testpmd: add flow validate/create commands Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 11/22] app/testpmd: add flow query command Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 12/22] app/testpmd: add rte_flow item spec handler Adrien Mazarguil
2016-12-16 3:01 ` Pei, Yulong
2016-12-16 9:17 ` Adrien Mazarguil
2016-12-16 12:22 ` Xing, Beilei
2016-12-16 15:25 ` Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 13/22] app/testpmd: add rte_flow item spec prefix length Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 14/22] app/testpmd: add rte_flow bit-field support Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 15/22] app/testpmd: add item any to flow command Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 16/22] app/testpmd: add various items " Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 17/22] app/testpmd: add item raw " Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 18/22] app/testpmd: add items eth/vlan " Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 19/22] app/testpmd: add items ipv4/ipv6 " Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 20/22] app/testpmd: add L4 items " Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 21/22] app/testpmd: add various actions " Adrien Mazarguil
2016-11-16 16:23 ` [dpdk-dev] [PATCH 22/22] app/testpmd: add queue " Adrien Mazarguil
2016-11-21 9:23 ` [dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow) Nélio Laranjeiro
2016-11-28 10:03 ` Pei, Yulong
2016-12-01 8:39 ` Adrien Mazarguil
2016-12-02 16:58 ` Ferruh Yigit
2016-12-08 15:19 ` Adrien Mazarguil
2016-12-08 17:56 ` Ferruh Yigit
2016-12-15 12:20 ` Ferruh Yigit
2016-12-16 8:22 ` Adrien Mazarguil
2016-12-16 16:24 ` [dpdk-dev] [PATCH v2 00/25] " Adrien Mazarguil
2016-12-16 16:24 ` [dpdk-dev] [PATCH v2 01/25] ethdev: introduce generic flow API Adrien Mazarguil
2017-10-23 8:53 ` Zhao1, Wei
2017-10-31 17:45 ` Adrien Mazarguil
2017-11-07 6:56 ` Zhao1, Wei
2017-11-14 3:23 ` Zhao1, Wei
2016-12-16 16:24 ` [dpdk-dev] [PATCH v2 02/25] doc: add rte_flow prog guide Adrien Mazarguil
2016-12-19 10:45 ` Mcnamara, John
2016-12-19 11:10 ` Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 03/25] doc: announce depreciation of legacy filter types Adrien Mazarguil
2016-12-19 10:47 ` Mcnamara, John
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 04/25] cmdline: add support for dynamic tokens Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 05/25] cmdline: add alignment constraint Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 06/25] app/testpmd: implement basic support for rte_flow Adrien Mazarguil
2016-12-19 8:37 ` Xing, Beilei
2016-12-19 10:19 ` Adrien Mazarguil
2016-12-20 1:57 ` Xing, Beilei
2016-12-20 9:38 ` Adrien Mazarguil
2016-12-21 5:23 ` Xing, Beilei
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 07/25] app/testpmd: add flow command Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 08/25] app/testpmd: add rte_flow integer support Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 09/25] app/testpmd: add flow list command Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 10/25] app/testpmd: add flow flush command Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 11/25] app/testpmd: add flow destroy command Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 12/25] app/testpmd: add flow validate/create commands Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 13/25] app/testpmd: add flow query command Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 14/25] app/testpmd: add rte_flow item spec handler Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 15/25] app/testpmd: add rte_flow item spec prefix length Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 16/25] app/testpmd: add rte_flow bit-field support Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 17/25] app/testpmd: add item any to flow command Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 18/25] app/testpmd: add various items " Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 19/25] app/testpmd: add item raw " Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 20/25] app/testpmd: add items eth/vlan " Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 21/25] app/testpmd: add items ipv4/ipv6 " Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 22/25] app/testpmd: add L4 items " Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 23/25] app/testpmd: add various actions " Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 24/25] app/testpmd: add queue " Adrien Mazarguil
2016-12-16 16:25 ` [dpdk-dev] [PATCH v2 25/25] doc: describe testpmd " Adrien Mazarguil
2016-12-17 22:06 ` [dpdk-dev] [PATCH v2 00/25] Generic flow API (rte_flow) Olga Shern
2016-12-19 17:48 ` [dpdk-dev] [PATCH v3 " Adrien Mazarguil
2016-12-19 17:48 ` [dpdk-dev] [PATCH v3 01/25] ethdev: introduce generic flow API Adrien Mazarguil
2017-05-23 6:07 ` Zhao1, Wei
2017-05-23 9:50 ` Adrien Mazarguil
2017-05-24 3:32 ` Zhao1, Wei
2017-05-24 7:32 ` Adrien Mazarguil
2017-05-24 8:46 ` Zhao1, Wei
2016-12-19 17:48 ` [dpdk-dev] [PATCH v3 02/25] doc: add rte_flow prog guide Adrien Mazarguil
2016-12-20 16:30 ` Mcnamara, John
2016-12-19 17:48 ` [dpdk-dev] [PATCH v3 03/25] doc: announce deprecation of legacy filter types Adrien Mazarguil
2016-12-19 17:48 ` [dpdk-dev] [PATCH v3 04/25] cmdline: add support for dynamic tokens Adrien Mazarguil
2016-12-19 17:48 ` [dpdk-dev] [PATCH v3 05/25] cmdline: add alignment constraint Adrien Mazarguil
2016-12-19 17:48 ` [dpdk-dev] [PATCH v3 06/25] app/testpmd: implement basic support for rte_flow Adrien Mazarguil
2016-12-19 17:48 ` [dpdk-dev] [PATCH v3 07/25] app/testpmd: add flow command Adrien Mazarguil
2016-12-20 16:13 ` Ferruh Yigit
2016-12-19 17:48 ` [dpdk-dev] [PATCH v3 08/25] app/testpmd: add rte_flow integer support Adrien Mazarguil
2016-12-19 17:48 ` [dpdk-dev] [PATCH v3 09/25] app/testpmd: add flow list command Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 10/25] app/testpmd: add flow flush command Adrien Mazarguil
2016-12-20 7:32 ` Zhao1, Wei
2016-12-20 9:45 ` Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 11/25] app/testpmd: add flow destroy command Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 12/25] app/testpmd: add flow validate/create commands Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 13/25] app/testpmd: add flow query command Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 14/25] app/testpmd: add rte_flow item spec handler Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 15/25] app/testpmd: add rte_flow item spec prefix length Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 16/25] app/testpmd: add rte_flow bit-field support Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 17/25] app/testpmd: add item any to flow command Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 18/25] app/testpmd: add various items " Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 19/25] app/testpmd: add item raw " Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 20/25] app/testpmd: add items eth/vlan " Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 21/25] app/testpmd: add items ipv4/ipv6 " Adrien Mazarguil
2016-12-20 9:21 ` Pei, Yulong
2016-12-20 10:02 ` Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 22/25] app/testpmd: add L4 items " Adrien Mazarguil
2016-12-20 9:14 ` Pei, Yulong
2016-12-20 9:50 ` Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 23/25] app/testpmd: add various actions " Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 24/25] app/testpmd: add queue " Adrien Mazarguil
2016-12-19 17:49 ` [dpdk-dev] [PATCH v3 25/25] doc: describe testpmd " Adrien Mazarguil
2016-12-19 20:44 ` Mcnamara, John
2016-12-20 10:51 ` Adrien Mazarguil
2016-12-20 17:06 ` Ferruh Yigit
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 00/25] Generic flow API (rte_flow) Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 01/25] ethdev: introduce generic flow API Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 02/25] doc: add rte_flow prog guide Adrien Mazarguil
2016-12-21 10:55 ` Mcnamara, John
2016-12-21 11:31 ` Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 03/25] doc: announce deprecation of legacy filter types Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 04/25] cmdline: add support for dynamic tokens Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 05/25] cmdline: add alignment constraint Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 06/25] app/testpmd: implement basic support for rte_flow Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 07/25] app/testpmd: add flow command Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 08/25] app/testpmd: add rte_flow integer support Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 09/25] app/testpmd: add flow list command Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 10/25] app/testpmd: add flow flush command Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 11/25] app/testpmd: add flow destroy command Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 12/25] app/testpmd: add flow validate/create commands Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 13/25] app/testpmd: add flow query command Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 14/25] app/testpmd: add rte_flow item spec handler Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 15/25] app/testpmd: add rte_flow item spec prefix length Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 16/25] app/testpmd: add rte_flow bit-field support Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 17/25] app/testpmd: add item any to flow command Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 18/25] app/testpmd: add various items " Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 19/25] app/testpmd: add item raw " Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 20/25] app/testpmd: add items eth/vlan " Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 21/25] app/testpmd: add items ipv4/ipv6 " Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 22/25] app/testpmd: add L4 items " Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 23/25] app/testpmd: add various actions " Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 24/25] app/testpmd: add queue " Adrien Mazarguil
2016-12-20 18:42 ` [dpdk-dev] [PATCH v4 25/25] doc: describe testpmd " Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 00/26] Generic flow API (rte_flow) Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 01/26] ethdev: introduce generic flow API Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 02/26] doc: add rte_flow prog guide Adrien Mazarguil
2016-12-21 15:09 ` Mcnamara, John
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 03/26] doc: announce deprecation of legacy filter types Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 04/26] cmdline: add support for dynamic tokens Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 05/26] cmdline: add alignment constraint Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 06/26] app/testpmd: implement basic support for rte_flow Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 07/26] app/testpmd: add flow command Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 08/26] app/testpmd: add rte_flow integer support Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 09/26] app/testpmd: add flow list command Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 10/26] app/testpmd: add flow flush command Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 11/26] app/testpmd: add flow destroy command Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 12/26] app/testpmd: add flow validate/create commands Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 13/26] app/testpmd: add flow query command Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 14/26] app/testpmd: add rte_flow item spec handler Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 15/26] app/testpmd: add rte_flow item spec prefix length Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 16/26] app/testpmd: add rte_flow bit-field support Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 17/26] app/testpmd: add item any to flow command Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 18/26] app/testpmd: add various items " Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 19/26] app/testpmd: add item raw " Adrien Mazarguil
2017-05-11 6:53 ` Zhao1, Wei
2017-05-12 9:12 ` Adrien Mazarguil
2017-05-16 5:05 ` Zhao1, Wei
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 20/26] app/testpmd: add items eth/vlan " Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 21/26] app/testpmd: add items ipv4/ipv6 " Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 22/26] app/testpmd: add L4 items " Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 23/26] app/testpmd: add various actions " Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 24/26] app/testpmd: add queue " Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 25/26] doc: describe testpmd " Adrien Mazarguil
2016-12-21 14:51 ` [dpdk-dev] [PATCH v5 26/26] app/testpmd: add protocol fields to " Adrien Mazarguil
2016-12-23 9:30 ` [dpdk-dev] [PATCH v5 00/26] Generic flow API (rte_flow) Thomas Monjalon
2016-12-21 16:19 ` [dpdk-dev] [PATCH v2 00/25] " Simon Horman
2016-12-22 12:48 ` Adrien Mazarguil
2017-01-04 9:53 ` Simon Horman
2017-01-04 18:12 ` Adrien Mazarguil
2017-01-04 19:34 ` John Fastabend
2016-08-01 15:08 [dpdk-dev] [RFC] Generic flow director/filtering/classification API Kieran Mansley
2016-08-03 15:19 ` Adrien Mazarguil
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=20160707102650.GU7621@6wind.com \
--to=adrien.mazarguil@6wind.com \
--cc=ajit.khaparde@broadcom.com \
--cc=alejandro.lucero@netronome.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.com \
--cc=jan@semihalf.com \
--cc=jerin.jacob@caviumnetworks.com \
--cc=jing.d.chen@intel.com \
--cc=jingjing.wu@intel.com \
--cc=johndale@cisco.com \
--cc=konstantin.ananyev@intel.com \
--cc=matejvido@gmail.com \
--cc=olgas@mellanox.com \
--cc=pablo.de.lara.guarch@intel.com \
--cc=rahul.lakkireddy@chelsio.com \
--cc=rasesh.mody@qlogic.com \
--cc=sony.chacko@qlogic.com \
--cc=thomas.monjalon@6wind.com \
--cc=wenzhuo.lu@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).