From: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.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, 21 Jul 2016 03:18:11 +0000 [thread overview]
Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC090903492F92@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <20160720104115.GN7621@6wind.com>
Hi Adrien,
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, July 20, 2016 6:41 PM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody;
> Ajit Khaparde; Rahul Lakkireddy; Jan Medala; John Daley; Chen, Jing D; Ananyev,
> Konstantin; Matej Vido; Alejandro Lucero; Sony Chacko; Jerin Jacob; De Lara
> Guarch, Pablo; Olga Shern
> Subject: Re: [RFC] Generic flow director/filtering/classification API
>
> Hi Wenzhuo,
>
> On Wed, Jul 20, 2016 at 02:16:51AM +0000, Lu, Wenzhuo wrote:
> [...]
> > > So, today an application cannot combine N-tuple and FDIR flow rules
> > > and get a reliable outcome, unless it is designed for specific
> > > devices with a known behavior.
> > >
> > > > What's the right behavior of PMD if APP want to create a flow
> > > > director rule
> > > which has a higher or even equal priority than an existing n-tuple
> > > rule? Should PMD return fail?
> > >
> > > First remember applications only deal with the generic API, PMDs are
> > > responsible for choosing the most appropriate HW implementation to
> > > use according to the requested flow rules (FDIR, N-tuple or anything else).
> > >
> > > For the specific case of FDIR vs N-tuple, if the underlying HW
> > > supports both I do not see why the PMD would create a N-tuple rule.
> > > Doesn't FDIR support everything N-tuple can do and much more?
> > Talking about the filters, fdir can cover n-tuple. I think that's why i40e only
> supports fdir but not n-tuple. But n-tuple has its own highlight. As we know, at
> least on intel NICs, fdir only supports per device mask. But n-tuple can support
> per rule mask.
> > As every pattern has spec and mask both, we cannot guarantee the masks are
> same. I think ixgbe will try to use n-tuple first if can. Because even the masks are
> different, we can support them all.
>
> OK, makes sense. In that case existing rules may indeed prevent subsequent
> ones from getting created if their priority is wrong. I do not think there is a way
> around that if the application needs this exact ordering.
Agree. I don’t see any workaround either. PMD has to return fail sometimes.
>
> > > Assuming such a thing happened anyway, that the PMD had to create a
> > > rule using a high priority filter type and that the application
> > > requests the creation of a rule that can only be done using a lower
> > > priority filter type, but also requested a higher priority for that rule, then yes,
> it should obviously fail.
> > >
> > > That is, unless the PMD can perform some kind of workaround to have both.
> > >
> > > > If so, do we need more fail reasons? According to this RFC, I
> > > > think we need
> > > return " EEXIST: collision with an existing rule. ", but it's not
> > > very clear, APP doesn't know the problem is priority, maybe more detailed
> reason is helpful.
> > >
> > > Possibly, I've defined a basic set of errors, there are quite a
> > > number of errno values to choose from. However I think we should not
> define too many values.
> > > In my opinion the basic set covers every possible failure:
> > >
> > > - EINVAL: invalid format, rule is broken or cannot be understood by the PMD
> > > anyhow.
> > >
> > > - ENOTSUP: pattern/actions look fine but something in the requested rule is
> > > not supported and thus cannot be applied.
> > >
> > > - EEXIST: pattern/actions are fine and could have been applied if only some
> > > other rule did not prevent the PMD to do it (I see it as the closest thing
> > > to "ETOOBAD" which unfortunately does not exist).
> > >
> > > - ENOMEM: like EEXIST, except it is due to the lack of resources not because
> > > of another rule. I wasn't sure which of ENOMEM or ENOSPC was better but
> > > settled on ENOMEM as it is well known. Still open to debate.
> > >
> > > Errno values are only useful to get a rough idea of the reason, and
> > > another mechanism is needed to pinpoint the exact problem for
> > > debugging/reporting purposes, something like:
> > >
> > > enum rte_flow_error_type {
> > > RTE_FLOW_ERROR_TYPE_NONE,
> > > RTE_FLOW_ERROR_TYPE_UNKNOWN,
> > > RTE_FLOW_ERROR_TYPE_PRIORITY,
> > > RTE_FLOW_ERROR_TYPE_PATTERN,
> > > RTE_FLOW_ERROR_TYPE_ACTION,
> > > };
> > >
> > > struct rte_flow_error {
> > > enum rte_flow_error_type type;
> > > void *offset; /* Points to the exact pattern item or action. */
> > > const char *message;
> > > };
> > When we are using a CLI and it fails, normally it will let us know
> > which parameter is not appropriate. So, I think it’s a good idea to
> > have this error structure :)
>
> Agreed.
>
> > > Then either provide an optional struct rte_flow_error pointer to
> > > rte_flow_validate(), or a separate function (rte_flow_analyze()?),
> > > since processing this may be quite expensive and applications may
> > > not care about the exact reason.
> > Agree the processing may be too expensive. Maybe we can say it's optional to
> return error details. And that's a good question that what APP should do if
> creating the rule fails. I believe normally it will choose handle the rule by itself.
> But I think it's not bad to feedback more. Or even the APP want to adjust the
> rules, it cannot be an option for lack of info.
>
> All right then, I'll add it to the specification.
>
> int
> rte_flow_validate(uint8_t port_id,
> const struct rte_flow_pattern *pattern,
> const struct rte_flow_actions *actions,
> struct rte_flow_error *error);
>
> With error possibly NULL if the application does not care. Is it fine for you?
Yes, it looks good to me. Thanks for that :)
>
> [...]
> > > > > > > - 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.
> > > > Does it mean PMD should store and maintain all the rules? Why not
> > > > let rte do
> > > that? I think if PMD maintain all the rules, it means every kind of
> > > NIC should have a copy of code for the rules. But if rte do that,
> > > only one copy of code need to be maintained, right?
> > >
> > > I've considered having rules stored in a common format understood at
> > > the RTE level and not specific to each PMD and decided that the
> > > opaque rte_flow pointer was a better choice for the following reasons:
> > >
> > > - Even though flow rules management is done in the control path, processing
> > > must be as fast as possible. Letting PMDs store flow rules using their own
> > > internal representation gives them the chance to achieve better
> > > performance.
> > Not quite understand. I think we're talking about maintain the rules by SW. I
> don’t think there's something need to be optimized according to specific NICs. If
> we need to optimize the code, I think we need to consider the CPU, OS ... and
> some common means. I'm wrong?
>
> Perhaps we were talking about different things, here I was only explaining why
> rte_flow (the result of creating a flow rule) should be opaque and fully managed
> by the PMD. More on the SW side of things below.
>
> > > - An opaque context managed by PMDs would probably have to be stored
> > > somewhere as well anyway.
> > >
> > > - PMDs may not need to allocate/store anything at all if they exclusively
> > > rely on HW state for everything. In my opinion, the generic API has enough
> > > constraints for this to work and maintain consistency between flow
> > > rules. Note this is currently how most PMDs implement FDIR and other
> > > filter types.
> > Yes, the rules are stored by HW. But considering stop/start the device, the
> rules in HW will lose. we have to store the rules by SW and re-program them
> when restarting the device.
>
> Assume a HW capable of keeping flow rules programmed even during a
> stop/start cycle (e.g. mlx4/mlx5 may be able to do it from DPDK point of view),
> don't you think it is more efficient to standardize on this behavior and let PMDs
> restore flow rules for HW that do not support it regardless of whether it would
> be done by RTE or the application (SW)?
Didn’t know that. As some NICs have already had the ability to keep the rules during a stop/start cycle, maybe it could be a trend :)
>
> > And in existing code, we store the filters by SW at least on Intel NICs. But I
> think we cannot reuse them, because considering the priority and which
> category of filter should be chosen, I think we need a whole new table for
> generic API. I think it’s what's designed now, right?
>
> So I understand you'd want RTE to help your PMD keep track of the flow rules it
> created?
Yes. But as you said before, it’s not a good idea for mlx4/mlx5, because their HW doesn't need SW to re-program the rules after stopping/starting. If we make it a common mechanism, it just wastes time for mlx4/mlx5.
>
> Nothing wrong with that, all I'm saying is that it should be entirely optional. RTE
> should not automatically maintain a list. PMDs have to call RTE helpers if they
> need help to maintain a context. These helpers are not defined in this API yet
> because it is difficult to know what will be useful in advance.
>
> > > - RTE can (and will) provide helpers to avoid most of the code redundancy,
> > > PMDs are free to use them or manage everything by themselves.
> > >
> > > - Given that the opaque rte_flow pointer associated with a flow rule is to
> > > be stored by the application, PMDs do not even have to keep references to
> > > them.
> > Don’t understand. More details?
>
> In an application:
>
> rte_flow *foo = rte_flow_create(...);
>
> In the above example, foo cannot be dereferenced by the application nor RTE,
> only the PMD is aware of its contents. This object can only be used with
> rte_flow*() functions.
>
> PMDs are thus free to make this object grow as needed when adding internal
> features without breaking any kind of public API/ABI.
>
> What I meant is, given that the application is supposed to store foo somewhere
> in order to destroy it later, the PMD does not have to keep track of that pointer
> assuming it does not need to access it later on its own for some reason.
>
> > > - The flow rules format described in this specification (pattern / actions)
> > > will be used by applications directly, and will be free to arrange them in
> > > lists, trees or in any other way if they need to keep flow specifications
> > > around for further processing.
> > Who will create the lists, trees or something else? According to previous
> discussion, I think the APP will program the rules one by one. So if APP organize
> the rules to lists, trees..., PMD doesn’t know that.
> > And you said " Given that the opaque rte_flow pointer associated with a flow
> rule is to be stored by the application ". I'm lost here.
>
> I guess that's because we're discussing two different things, flow rule
> specifications and flow rule objects. Let me sum it up:
>
> - Flow rule specifications are the patterns/actions combinations provided by
> applications to rte_flow_create(). Applications can store those as needed
> and organize them as they wish (hash, tree, list). Neither PMDs nor RTE
> will do it for them.
>
> - Flow rule objects (struct rte_flow *) are generated when a flow rule is
> created. Applications must keep these around if they want to manipulate
> them later (i.e. destroy or query existing rules).
Thanks for this clarification. So the specifications can be different with objects, right? The specifications are what the APP wants, the objects are what the APP really gets. As rte_flow_create can fail. Right?
>
> Then PMDs *may* need to keep and arrange flow rule objects internally for
> management purposes. Could be because HW requires it, detecting conflicting
> rules, managing priorities and so on. Possible reasons are not described in this
> API because these are thought as PMD-specific needs.
Got it.
>
> > > > When the port is stopped and restarted, rte can reconfigure the
> > > > rules. Is the
> > > concern that PMD may adjust the sequence of the rules according to
> > > the priority, so every NIC has a different list of rules? But PMD
> > > can adjust them again when rte reconfiguring the rules.
> > >
> > > What about PMDs able to stop and restart ports without destroying
> > > their own flow rules? If we assume flow rules must be destroyed when
> > > stopping a port, these PMDs are needlessly penalized with slower
> > > stop/start cycles. Think about it assuming thousands of flow rules.
> > I believe the rules maintained by SW should not be destroyed, because they're
> used to be re-programed when the device starts again.
>
> Do we agree that applications should not care? Flow rules configured before
> stopping a port must still be there after restarting it.
Yes, agree.
>
> What we seem to not agree about is that you think RTE should be responsible
> for restoring flow rules of devices that lose them when stopped. I think doing so
> is unfair to devices for which it is not the case and not really nice to applications,
> so my opinion is that the PMD is responsible for restoring flow rules however it
> wants. It is free to use RTE helpers to keep their track, as long as it's all managed
> internally.
What I think is RTE can store the flow rules and recreate them after restarting, in the function like rte_dev_start, so APP knows nothing about it. But according to the discussing above, I think the design doesn't support it, right?
RTE doesn't store the flow rules objects and event it stores them, there's no way designed to re-program the objects. And also considering some HW doesn't need to be re-programed. I think it's OK to let PMD maintain the rules as the re-programing is a NIC specific requirement.
>
> > > Thus from an application point of view, whatever happens when
> > > stopping and restarting a port should not matter. If a flow rule was
> > > present before, it must still be present afterwards. If the PMD had
> > > to destroy flow rules and re-create them, it does not actually matter if they
> differ slightly at the HW level, as long as:
> > >
> > > - Existing opaque flow rule pointers (rte_flow) are still valid to the PMD
> > > and refer to the same rules.
> > >
> > > - The overall behavior of all rules is the same.
> > >
> > > The list of rules you think of (patterns / actions) is maintained by
> > > applications (not RTE), and only if they need them. RTE would needlessly
> duplicate this.
> > As said before, need more details to understand this. Maybe an example
> > is better :)
>
> The generic format both RTE and applications might understand is the one
> described in this API (struct rte_flow_pattern and struct rte_flow_actions).
>
> If we wanted RTE to maintain some sort of per-port state for flow rule
> specifications, it would have to be a copy of these structures arranged somehow
> (list or something else).
>
> If we consider that PMDs need to keep a context object associated to a flow
> rule (the opaque struct rte_flow *), then RTE would most likely have to store it
> along with the flow specification.
>
> Such a list may not be useful to applications (list lookups take time), so they
> would implement their own redundant method. They might also require extra
> room to attach some application context to flow rules. A generic list cannot plan
> for it.
>
> Applications know what they want to do with flow rules and are responsible for
> managing them efficiently with RTE out of the way.
>
> I'm not sure if this answered your question, if not, please describe a scenario
> where a RTE-managed list of flow rules would be mandatory.
Got your point and agree :)
>
> --
> Adrien Mazarguil
> 6WIND
next prev parent reply other threads:[~2016-07-21 3:18 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
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 [this message]
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=6A0DE07E22DDAD4C9103DF62FEBC090903492F92@shsmsx102.ccr.corp.intel.com \
--to=wenzhuo.lu@intel.com \
--cc=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 \
/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).