From: "Chandran, Sugesh" <sugesh.chandran@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>,
"Lu, Wenzhuo" <wenzhuo.lu@intel.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: Fri, 15 Jul 2016 09:23:26 +0000 [thread overview]
Message-ID: <2EF2F5C0CC56984AA024D0B180335FCB13DEE55F@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <20160713200327.GC7621@6wind.com>
Thank you Adrien,
Please find below for some more comments/inputs
Let me know your thoughts on this.
Regards
_Sugesh
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, July 13, 2016 9:03 PM
> To: Chandran, Sugesh <sugesh.chandran@intel.com>
> Cc: 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>; Lu, Wenzhuo <wenzhuo.lu@intel.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
>
> On Mon, Jul 11, 2016 at 10:42:36AM +0000, Chandran, Sugesh wrote:
> > Hi Adrien,
> >
> > Thank you for your response,
> > Please see my comments inline.
>
> Hi Sugesh,
>
> Sorry for the delay, please see my answers inline as well.
>
> [...]
> > > > > Flow director
> > > > > -------------
> > > > >
> > > > > Flow director (FDIR) is the name of the most capable filter
> > > > > type, which covers most features offered by others. As such, it
> > > > > is the most
> > > widespread
> > > > > in PMDs that support filtering (i.e. all of them besides **e1000**).
> > > > >
> > > > > It is also the only type that allows an arbitrary 32 bits value
> > > > > provided by applications to be attached to a filter and returned
> > > > > with matching packets instead of relying on the destination queue to
> recognize flows.
> > > > >
> > > > > Unfortunately, even FDIR requires applications to be aware of
> > > > > low-level capabilities and limitations (most of which come
> > > > > directly from **ixgbe**
> > > and
> > > > > **i40e**):
> > > > >
> > > > > - Bitmasks are set globally per device (port?), not per filter.
> > > > [Sugesh] This means application cannot define filters that matches
> > > > on
> > > arbitrary different offsets?
> > > > If that’s the case, I assume the application has to program
> > > > bitmask in
> > > advance. Otherwise how
> > > > the API framework deduce this bitmask information from the rules??
> > > > Its
> > > not very clear to me
> > > > that how application pass down the bitmask information for
> > > > multiple filters
> > > on same port?
> > >
> > > This is my understanding of how flow director currently works,
> > > perhaps someome more familiar with it can answer this question better
> than I could.
> > >
> > > Let me take an example, if particular device can only handle a
> > > single IPv4 mask common to all flow rules (say only to match
> > > destination addresses), updating that mask to also match the source
> > > address affects all defined and future flow rules simultaneously.
> > >
> > > That is how FDIR currently works and I think it is wrong, as it
> > > penalizes devices that do support individual bit-masks per rule, and
> > > is a little awkward from an application point of view.
> > >
> > > What I suggest for the new API instead is the ability to specify one
> > > bit-mask per rule, and let the PMD deal with HW limitations by
> > > automatically configuring global bitmasks from the first added rule,
> > > then refusing to add subsequent rules if they specify a conflicting
> > > bit-mask. Existing rules remain unaffected that way, and
> > > applications do not have to be extra cautious.
> > >
> > [Sugesh] The issue with that approach is, the hardware simply discards
> > the rule when it is a super set of first one eventhough the hardware
> > is capable of handling it. How its guaranteed the first rule will set
> > the bitmask for all the subsequent rules.
>
> Just to clarify, the API only says that new rules cannot affect existing ones
> (which I think makes sense from a user's perspective), so as long as the PMD
> does whatever is needed to make all rules work together, there should not
> be any problem with this approach.
>
> Even if the PMD has to temporarily remove an existing rule and reconfigure
> global masks in order to add subsequent rules, it is fine as long as packets
> aren't misdirected in the meantime (they may be dropped if there is no
> other choice).
[Sugesh] I feel this is fine. Thank you for confirming.
>
> > How about having a CLASSIFER_TYPE for the classifier. Every port can
> > have set of supported flow types(for eg: L3_TYPE, L4_TYPE,
> > L4_TYPE_8BYTE_FLEX,
> > L4_TYPE_16BYTE_FLEX) based on the underlying FDIR support. Application
> > can query this and set the type accordingly while initializing the
> > port. This way the first rule need not set all the bits that may needed in the
> future rules.
>
> Again from a user's POV, I think doing so would add unwanted HW-specific
> complexity.
>
> However this concern can be handled through a different approach. Let's say
> user creates a pattern that only specifies a IP header with a given bit-mask.
>
> In FDIR language this translates to:
>
> - Set global mask for IPv4 accordingly, remaining global masks all zeroed
> (assumed default value).
>
> - Create an IPv4 flow.
>
> From now on, all rules specifying a IPv4 header must have this exact bitmask
> (implicitly or explicitly), otherwise they cannot be created, i.e. the global
> bitmask for IPv4 becomes immutable.
>
> Now user creates a TCPv4 rule (as long as it uses the same IPv4 mask), to
> handle this FDIR would:
>
> - Keep global immutable mask for IPv4 unchanged, set global TCP mask
> according to the flow rule.
>
> - Create a TCPv4 flow.
>
> From this point on, like IPv4, subsequent TCP rules must have this exact
> bitmask and so on as the global bitmask becomes immutable.
>
> Basically, only protocol bit-masks affected by existing flow rules are
> immutable, others can be changed later. Global flow masks for protocols
> become mutable again when no existing flow rule uses them.
>
> Does it look fine for you?
[Sugesh] This looks fine for me.
>
> [...]
> > > > > +--------------------------+
> > > > > | Copy to queue 8 |
> > > > > +==========+===============+
> > > > > | PASSTHRU | |
> > > > > +----------+-----------+---+
> > > > > | QUEUE | ``queue`` | 8 |
> > > > > +----------+-----------+---+
> > > > >
> > > > > ``ID``
> > > > > ^^^^^^
> > > > >
> > > > > Attaches a 32 bit value to packets.
> > > > >
> > > > > +----------------------------------------------+
> > > > > | ID |
> > > > > +========+=====================================+
> > > > > | ``id`` | 32 bit value to return with packets |
> > > > > +--------+-------------------------------------+
> > > > >
> > > > [Sugesh] I assume the application has to program the flow with a
> > > > unique ID and matching packets are stamped with this ID when
> > > > reporting to the software. The uniqueness of ID is NOT guaranteed
> > > > by the API framework. Correct me if I am wrong here.
> > >
> > > You are right, if the way I wrote it is not clear enough, I'm open
> > > to suggestions to improve it.
> > [Sugesh] I guess its fine and would like to confirm the same. Perhaps
> > it would be nice to mention that the IDs are application defined.
>
> OK, I will make it clearer.
>
> > > > [Sugesh] Is it a limitation to use only 32 bit ID? Is it possible
> > > > to have a
> > > > 64 bit ID? So that application can use the control plane flow
> > > > pointer Itself as an ID. Does it make sense?
> > >
> > > I've specified a 32 bit ID for now because this is what FDIR
> > > supports and also what existing devices can report today AFAIK (i40e and
> mlx5).
> > >
> > > We could use 64 bit for future-proofness in a separate action like "ID64"
> > > when at least one device supports it.
> > >
> > > To PMD maintainers: please comment if you know devices that support
> > > tagging matching packets with more than 32 bits of user-provided
> > > data!
> > [Sugesh] I guess the flow director ID is 64 bit , The XL710 datasheet says so.
> > And in the 'rte_mbuf' structure the 64 bit FDIR-ID is shared with rss
> > hash. This can be a software driver limitation that expose only 32
> > bit. Possibly because of cache alignment issues? Since the hardware
> > can support 64 bit, I feel it make sense to support 64 bit as well.
>
> I agree we need 64 bit support, but then we also need a solution for devices
> that support only 32 bit. Possible methods I can think of:
>
> - A separate "ID64" action (or a "ID32" one, perhaps with a better name).
>
> - A single ID action with an unlimited number of bytes to return with
> packets (would actually be a string). PMDs can then refuse to create flow
> rules requesting an unsupported number of bytes. Devices supporting
> fewer
> than 32 bits are also included this way without the need for yet another
> action.
>
> Thoughts?
[Sugesh] I feel the single ID approach is much better. But I would say a fixed size ID
is easy to handle at upper layers. Say PMD returns 64bit ID in which MSBs
are masked out, based on how many bits the hardware can support.
PMD can refuse the unsupported number of bytes when requested. So the size
of ID going to be a parameter to program the flow.
What do you think?
>
> [...]
> > > > [Sugesh] Another concern is the cost and time of installing these
> > > > rules in the hardware. Can we make these APIs time bound(or at
> > > > least an option
> > > to
> > > > set the time limit to execute these APIs), so that Application
> > > > doesn’t have to wait so long when installing and deleting flows
> > > with
> > > > slow hardware/NIC. What do you think? Most of the datapath flow
> > > installations are
> > > > dynamic and triggered only when there is an ingress traffic. Delay
> > > > in flow insertion/deletion have unpredictable
> > > consequences.
> > >
> > > This API is (currently) aimed at the control path only, and must
> > > indeed be assumed to be slow. Creating million of rules may take
> > > quite long as it may involve syscalls and other time-consuming
> > > synchronization things on the PMD side.
> > >
> > > So currently there is no plan to have rules added from the data path
> > > with time constraints. I think it would be implemented through a
> > > different set of functions anyway.
> > >
> > > I do not think adding time limits is practical, even specifying in
> > > the API that creating a single flow rule must take less than a
> > > maximum number of seconds in order to be effective is too much of a
> > > constraint (applications that create all flows during init may not care after
> all).
> > >
> > > You should consider in any case that modifying flow rules will
> > > always be slower than receiving packets, there is no way around
> > > that. Applications have to live with it and provide a software
> > > fallback for incoming packets while managing flow rules.
> > >
> > > Moreover, think about what happens when you hit the maximum
> number
> > > of flow rules and cannot create any more. Applications need to
> > > implement some kind of fallback in their data path.
> > >
> > > Offloading flows in HW is also only useful if they live much longer
> > > than the time taken to create and delete them. Perhaps applications
> > > may choose to do so after detecting long lived flows such as TCP
> > > sessions.
> > >
> > > You may have one separate control thread dedicated to manage flows
> > > and keep your normal control thread unaffected by delays. Several
> > > threads can even be dedicated, one per device.
> > [Sugesh] I agree that the flow insertion cannot be as fast as the
> > packet receiving rate. From application point of view the problem
> > will be when hardware flow insertion takes longer than software flow
> > insertion. At least application has to know the cost of
> > inserting/deleting a rule in hardware beforehand. Otherwise how
> > application can choose the right flow candidate for hardware. My point
> here is application is expecting a deterministic behavior from a classifier while
> inserting and deleting rules.
>
> Understood, however it will be difficult to estimate, particularly if a PMD
> must rearrange flow rules to make room for a new one due to priority levels
> collision or some other HW-related reason. I mean, spent time cannot be
> assumed to be constant, even PMDs cannot know in advance because it also
> depends on the performance of the host CPU.
>
> Such applications may find it easier to measure elapsed time for the rules
> they create, make statistics and extrapolate from this information for future
> rules. I do not think the PMD can help much here.
[Sugesh] From an application point of view this can be an issue.
Even there is a security concern when we program a short lived flow. Lets consider the case,
1) Control plane programs the hardware with Queue termination flow.
2) Software dataplane programmed to treat the packets from the specific queue accordingly.
3) Remove the flow from the hardware. (Lets consider this is a long wait process..).
Or even there is a chance that hardware take more time to report the status than removing it
physically . Now the packets in the queue no longer consider as matched/flow hit.
. This is due to the software dataplane update is yet to happen.
We must need a way to sync between software datapath and classifier APIs even though
they are both programmed from a different control thread.
Are we saying these APIs are only meant for user defined static flows??
>
> > > > [Sugesh] Another query is on the synchronization part. What if
> > > > same rules
> > > are
> > > > handled from different threads? Is application responsible for
> > > > handling the
> > > concurrent
> > > > hardware programming?
> > >
> > > Like most (if not all) DPDK APIs, applications are responsible for
> > > managing locking issues as decribed in 4.3 (Behavior). Since this is
> > > a control path API and applications usually have a single control
> > > thread, locking should not be necessary in most cases.
> > >
> > > Regarding my above comment about using several control threads to
> > > manage different devices, section 4.3 says:
> > >
> > > "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."
> > >
> > > I'd like to emphasize it is not "per port" but "per device", since
> > > in a few cases a configurable resource is shared by several ports.
> > > It may be difficult for applications to determine which ports are
> > > shared by a given device but this falls outside the scope of this API.
> > >
> > > Do you think adding the guarantee that it is always safe to
> > > configure two different ports simultaneously without locking from
> > > the application side is necessary? In which case the PMD would be
> > > responsible for locking shared resources.
> > [Sugesh] This would be little bit complicated when some of ports are
> > not under DPDK itself(what if one port is managed by Kernel) Or ports
> > are tied by different application. Locking in PMD helps when the ports
> > are accessed by multiple DPDK application. However what if the port itself
> not under DPDK?
>
> Well, either we do not care about what happens outside of the DPDK
> context, or PMDs must find a way to satisfy everyone. I'm not a fan of locking
> either but it would be nice if flow rules configuration could be attempted on
> different ports simultaneously without the risk of wrecking anything, so that
> applications do not need to care.
>
> Possible cases for a dual port device with global flow rule settings affecting
> both ports:
>
> 1) ports 1 & 2 are managed by DPDK: this is the easy case, a rule that needs
> to alter a global setting necessary for an existing rule on any port is
> not allowed (EEXIST). PMD must maintain a device context common to both
> ports in order for this to work. This context is either under lock, or
> the first port on which a flow rule is created owns all future flow
> rules.
>
> 2) port 1 is managed by DPDK, port 2 by something else, the PMD is aware of
> it and knows that port 2 may modify the global context: no flow rules can
> be created from the DPDK application due to safety issues (EBUSY?).
>
> 3) port 1 is managed by DPDK, port 2 by something else, the PMD is aware of
> it and knows that port 2 will not modify flow rules: PMD should not care,
> no lock necessary.
>
> 4) port 1 is managed by DPDK, port 2 by something else and the PMD is not
> aware of it: either flow rules cannot be created ever at all, or we say
> it is user's reponsibility to make sure this does not happen.
>
> Considering that most control operations performed by DPDK affect the
> device regardless of other applications, I think 1) is the only case that should
> be defined, otherwise 4), defined as user's responsibility.
>
> > > > > Destruction
> > > > > ~~~~~~~~~~~
> > > > >
> > > > > Flow rules destruction is not automatic, and a queue should not
> > > > > be
> > > released
> > > > > if any are still attached to it. Applications must take care of
> > > > > performing this step before releasing resources.
> > > > >
> > > > > ::
> > > > >
> > > > > int
> > > > > rte_flow_destroy(uint8_t port_id,
> > > > > struct rte_flow *flow);
> > > > >
> > > > >
> > > > [Sugesh] I would suggest having a clean-up API is really useful as
> > > > the
> > > releasing of
> > > > Queue(is it applicable for releasing of port too?) is not
> > > > guaranteeing the
> > > automatic flow
> > > > destruction.
> > >
> > > Would something like rte_flow_flush(port_id) do the trick? I wanted
> > > to emphasize in this first draft that applications should really
> > > keep the flow pointers around in order to manage/destroy them. It is
> > > their responsibility, not PMD's.
> > [Sugesh] Thanks, I think the flush call will do.
>
> Noted, will add it.
>
> > > > This way application can initialize the port, clean-up all the
> > > > existing rules and create new rules on a clean slate.
> > >
> > > No resource can be released as long as a flow rule is using it (bad
> > > things may happen otherwise), all flow rules must be destroyed
> > > first, thus none can possibly remain after initializing a port. It
> > > is assumed that PMDs do automatic clean up during init if necessary to
> ensure this.
> > [Sugesh] That will do.
>
> I will make it more explicit as well.
>
> [...]
>
> --
> Adrien Mazarguil
> 6WIND
next prev parent reply other threads:[~2016-07-15 9:23 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
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 [this message]
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=2EF2F5C0CC56984AA024D0B180335FCB13DEE55F@IRSMSX102.ger.corp.intel.com \
--to=sugesh.chandran@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 \
--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).