From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
Date: Wed, 6 Jan 2016 18:22:48 +0100 [thread overview]
Message-ID: <20160106172248.GT12095@6wind.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725836AE2DBC@irsmsx105.ger.corp.intel.com>
On Wed, Jan 06, 2016 at 04:44:43PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Wednesday, January 06, 2016 3:45 PM
> > To: Ananyev, Konstantin
> > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> >
> > On Wed, Jan 06, 2016 at 02:29:07PM +0000, Ananyev, Konstantin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > > Sent: Wednesday, January 06, 2016 10:01 AM
> > > > To: Ananyev, Konstantin
> > > > Cc: Nélio Laranjeiro; Tan, Jianfeng; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set
> > > >
> > > > On Tue, Jan 05, 2016 at 04:50:31PM +0000, Ananyev, Konstantin wrote:
> > > > [...]
> > > > > > -----Original Message-----
> > > > > > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > > > [...]
> > > > > > I think we miss a comment here in how those 2/6/4 values are chosen
> > > > > > because, according to the mask, I expect 16 possibilities but I get
> > > > > > less. It will help a lot anyone who needs to add a new type.
> > > > > >
> > > > > > Extending the snprintf behavior above, it is best to remove the mask
> > > > > > argument altogether and have rte_eth_dev_get_ptype_info() return the
> > > > > > entire list every time. Applications need to iterate on the result in
> > > > > > any case.
> > > > >
> > > > > I think we'd better keep mask argument.
> > > > > In many cases upper layer only interested in some particular subset of
> > > > > all packet types that HW can recognise.
> > > > > Let say l3fwd only cares about RTE_PTYPE_L3_MASK, it is not interested in L4,
> > > > > tunnelling packet types, etc.
> > > > > If caller needs to know all recognised ptypes, he can set mask==-1,
> > > > > In that case all supported packet types will be returned.
> > > >
> > > > There are other drawbacks to the mask argument in my opinion. The API will
> > > > have to be updated again as soon as 32 bits aren't enough to represent all
> > > > possible masks. We can't predict it will be large enough forever but on the
> > > > other hand, using uint64_t seems overkill at this point.
> > >
> > > Inside rte_mbuf packet_type itself is a 32 bit value.
> > > These 32 bits are divided into several fields to mark packet types,
> > > i.e: bits [0-3] are for all possible L2 types, bits [4-7] for L3 types, etc.
> > > As long as packet_type itself is 32bits, 32bit mask is sufficient.
> > > If we'll ever run out of 32 bits in packet_type itself, it will be ABI change anyway.
> >
> > Sure, however why not do it now this issue has been raised so this function
> > doesn't need updating the day it breaks? I know there's a million other
> > places with a similar problem but I'm all for making new code future proof.
>
> If rte_mbuf packet_type will have to be increased to 64bit long, then
> this function will have to change anyway (with or without mask parameter).
> It will have to become:
>
> rte_eth_dev_get_ptype_info(uint8_t portid, uint64_t ptypes[], ...)
>
> So I think we don't have to worry about mask parameter itself.
Well, yes, besides I overlooked ptypes[] itself is 32 bit, working around
the type width of the mask wouldn't help much.
> > Perhaps in this particular case there is no way to hit the limit (although
> > there are only four unused bits left to extend RTE_PTYPE masks) but we've
> > seen this happen too many times with subsequent ABI breakage.
>
> When ptype was introduced we tried to reserve some free space for each layer (L2/L3/L4/...),
> so it wouldn't be overrun immediately.
> But of course if there would be a new HW that can recognise dozen new packet types - it is possible.
> Do you have any particular use-case in mind?
No, that was just to illustrate my point.
> > > > I think this use for masks should be avoided when performance does not
> > > > matter much, as in this case, user application cannot know the number of
> > > > entries in advance and must rely on the returned value to iterate.
> > >
> > > User doesn't know numbers of entries in advance anyway (with and without the mask).
> > > That's why this function was introduced at first place.
> > >
> > > With mask it just a bit more handy, in case user cares only about particular subset of supported
> > > packet types (only L2 let say).
> >
> > OK, so we definitely need something to let applications know the layer a
> > given packet type belongs to, I'm sure it can be done in a convenient way
> > that won't be limited to the underlying type of the mask.
> >
> > > > A helper function can be added to convert a RTE_PTYPE_* value to the layer
> > > > it belongs to (using enum to define possible values).
> > >
> > > Not sure what for?
> >
> > This is assuming rte_eth_dev_get_ptype_info() doesn't filter anything (no
> > "mask" argument). In that case a separate function must be added to convert
> > RTE_PTYPE_* values to a layer, so applications can look for interesting
> > packet types while parsing plist[] on their own.
>
> Honestly, I don't see why do you need that.
> You already do know that let say RTE_PTYPE_L3_IPV4 belongs to L3.
> Why do you need some extra enum here?
> From my thought - the only purpose of mask parameter was to limit number of elements in the ptypes[] at return.
> So let say user would need to iterate over 10 elements, instead of 100 to find
> the ones he is interested in.
Since this is already a slow manner for retrieving types, 10 or 100 doesn't
make much difference. Such a function shouldn't be used in the data path
directly.
My point is, since we're dealing with a slow function, let's keep its API as
simple as possible. By having a mask to match, a large number of checks are
added in all PMDs while they could just fill the array without
bothering. The filtering logic is an application requirement that could be
useful in its own function as well (converting any random value to its
related layer or mask).
> > This layer information could be defined as an enum, i.e.:
> >
> > enum rte_ptype_info {
> > RTE_PTYPE_UNKNOWN,
> > RTE_PTYPE_L2,
> > RTE_PTYPE_L3,
> > ...
> > };
> >
> > Or even an int value (2 standing for for "layer 2" etc. Tunnel encapsulation
> > wouldn't be described easily that way though). It's just an idea.
> >
> > > > If we absolutely want a mean to filter returned values, I suggest we use
> > > > this enum instead of the mask argument.
> > > > Since it won't be a mask, it won't
> > > > have to be updated every time a new protocol requires extending one.
> > >
> > > Number of bits PTYPE_L2/L3/L4,... layers are already defined.
> > > So let say RTE_PTYPE_L2_MASK shouldn't change if you'll add new L2 ptype -
> > > there are few reserved values right now.
> > > if one day we'll run out bits in let say RTE_PTYPE_L2_MASK and will have to increase its size -
> > > it would mean change of the packet_type layout and possible ABI breakage anyway.
> >
> > I'm aware of this, only pointing out we tend to rely on masks and type
> > boundaries a bit too much when there are other methods that are as (if not
> > more) convenient.
>
> Yes, we do rely on masks in ptype.
> That's how ptype was defined.
> Let say to check that incoming packet is Ether/IPv4(no extentions)/UDP,
> you probably would do:
>
> if (mbuf->packet_type & (RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK) ==
> (RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP)) {...}
All right, let's not use a different method to filter packet types.
> > Perhaps some sort of tunneled packet types beyond inner L4 consuming the
> > four remaining bits will be added? That could happen soon.
>
> As I said above: do you have particular scenario in mind when 32bits for packet_type
> might be not enough?
> If yes, then it is probably a good idea to submit an RFC for extending it to 64 bit,
> or introduce packet_type2, or whatever would be your preferred way to deal with it.
No, really, I guess we'll extend ptype to 64 bit when necessary. My point on
filtering separately still stands.
> Konstantin
>
--
Adrien Mazarguil
6WIND
next prev parent reply other threads:[~2016-01-06 17:23 UTC|newest]
Thread overview: 202+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-31 6:53 [dpdk-dev] [PATCH 00/12] Add API to get packet type info Jianfeng Tan
2015-12-31 6:53 ` [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet type is set Jianfeng Tan
2016-01-04 11:38 ` Adrien Mazarguil
2016-01-04 14:36 ` Ananyev, Konstantin
2016-01-05 16:14 ` Nélio Laranjeiro
2016-01-05 16:50 ` Ananyev, Konstantin
2016-01-06 10:00 ` Adrien Mazarguil
2016-01-06 14:29 ` Ananyev, Konstantin
2016-01-06 15:44 ` Adrien Mazarguil
2016-01-06 16:44 ` Ananyev, Konstantin
2016-01-06 17:22 ` Adrien Mazarguil [this message]
2016-01-07 10:24 ` Ananyev, Konstantin
2016-01-07 13:32 ` Adrien Mazarguil
2016-01-11 7:39 ` Tan, Jianfeng
2016-01-11 10:26 ` Ananyev, Konstantin
2015-12-31 6:53 ` [dpdk-dev] [PATCH 02/12] pmd/cxgbe: add dev_ptype_info_get implementation Jianfeng Tan
2016-01-06 7:11 ` Rahul Lakkireddy
2016-01-06 8:23 ` Tan, Jianfeng
2015-12-31 6:53 ` [dpdk-dev] [PATCH 03/12] pmd/e1000: " Jianfeng Tan
2015-12-31 6:53 ` [dpdk-dev] [PATCH 04/12] pmd/enic: " Jianfeng Tan
2015-12-31 6:53 ` [dpdk-dev] [PATCH 05/12] pmd/fm10k: " Jianfeng Tan
2015-12-31 6:53 ` [dpdk-dev] [PATCH 06/12] pmd/i40e: " Jianfeng Tan
2015-12-31 6:53 ` [dpdk-dev] [PATCH 07/12] pmd/ixgbe: " Jianfeng Tan
2016-01-04 18:12 ` Ananyev, Konstantin
2016-01-05 1:25 ` Tan, Jianfeng
2015-12-31 6:53 ` [dpdk-dev] [PATCH 08/12] pmd/mlx4: " Jianfeng Tan
2016-01-04 11:11 ` Adrien Mazarguil
2016-01-05 3:08 ` Tan, Jianfeng
2016-01-05 16:18 ` Adrien Mazarguil
2016-01-11 5:07 ` Tan, Jianfeng
2015-12-31 6:53 ` [dpdk-dev] [PATCH 09/12] pmd/mlx5: " Jianfeng Tan
2015-12-31 6:53 ` [dpdk-dev] [PATCH 10/12] pmd/nfp: " Jianfeng Tan
2015-12-31 6:53 ` [dpdk-dev] [PATCH 11/12] pmd/vmxnet3: " Jianfeng Tan
2015-12-31 6:53 ` [dpdk-dev] [PATCH 12/12] examples/l3fwd: add option to parse ptype Jianfeng Tan
2016-01-04 18:32 ` Ananyev, Konstantin
2016-01-05 2:44 ` Tan, Jianfeng
2016-01-05 16:49 ` Ananyev, Konstantin
2016-01-07 1:20 ` Tan, Jianfeng
2016-01-07 9:44 ` Ananyev, Konstantin
2016-01-13 1:52 ` [dpdk-dev] [PATCH 00/12] Add API to get packet type info Qiu, Michael
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 " Jianfeng Tan
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 01/12] ethdev: add API to query packet type filling info Jianfeng Tan
2016-01-15 13:58 ` Adrien Mazarguil
2016-01-15 15:11 ` Ananyev, Konstantin
2016-01-15 15:33 ` Adrien Mazarguil
2016-01-15 15:03 ` Ananyev, Konstantin
2016-02-25 6:53 ` Tan, Jianfeng
2016-02-25 11:17 ` Ananyev, Konstantin
2016-02-25 14:57 ` Tan, Jianfeng
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 02/12] pmd/cxgbe: add dev_ptype_info_get implementation Jianfeng Tan
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 03/12] pmd/e1000: " Jianfeng Tan
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 04/12] pmd/enic: " Jianfeng Tan
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 05/12] pmd/fm10k: " Jianfeng Tan
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 06/12] pmd/i40e: " Jianfeng Tan
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 07/12] pmd/ixgbe: " Jianfeng Tan
2016-01-15 14:50 ` Ananyev, Konstantin
2016-02-25 6:43 ` Tan, Jianfeng
2016-02-25 11:10 ` Ananyev, Konstantin
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 08/12] pmd/mlx4: " Jianfeng Tan
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 09/12] pmd/mlx5: " Jianfeng Tan
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 10/12] pmd/nfp: " Jianfeng Tan
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 11/12] pmd/vmxnet3: " Jianfeng Tan
2016-01-15 5:45 ` [dpdk-dev] [PATCH v2 12/12] examples/l3fwd: add option to parse ptype Jianfeng Tan
2016-01-15 14:47 ` Ananyev, Konstantin
2016-02-25 10:41 ` Tan, Jianfeng
2016-02-25 10:57 ` Ananyev, Konstantin
2016-02-23 17:31 ` [dpdk-dev] [PATCH v2 00/12] Add API to get packet type info Bruce Richardson
2016-02-25 7:53 ` [dpdk-dev] [PATCH v3 " Jianfeng Tan
2016-02-25 7:53 ` [dpdk-dev] [PATCH v3 01/12] ethdev: add API to query packet type filling info Jianfeng Tan
2016-02-25 15:46 ` Ananyev, Konstantin
2016-02-25 16:36 ` Tan, Jianfeng
2016-02-25 17:16 ` Ananyev, Konstantin
2016-02-26 1:42 ` Tan, Jianfeng
2016-02-25 7:53 ` [dpdk-dev] [PATCH v3 02/12] pmd/cxgbe: add dev_ptype_info_get implementation Jianfeng Tan
2016-02-25 7:53 ` [dpdk-dev] [PATCH v3 03/12] pmd/e1000: " Jianfeng Tan
2016-02-25 7:53 ` [dpdk-dev] [PATCH v3 04/12] pmd/enic: " Jianfeng Tan
2016-02-25 7:53 ` [dpdk-dev] [PATCH v3 05/12] pmd/fm10k: " Jianfeng Tan
2016-02-25 7:53 ` [dpdk-dev] [PATCH v3 06/12] pmd/i40e: " Jianfeng Tan
2016-02-25 7:53 ` [dpdk-dev] [PATCH v3 07/12] pmd/ixgbe: " Jianfeng Tan
2016-02-25 7:53 ` [dpdk-dev] [PATCH v3 08/12] pmd/mlx4: " Jianfeng Tan
2016-02-25 7:53 ` [dpdk-dev] [PATCH v3 09/12] pmd/mlx5: " Jianfeng Tan
2016-02-25 7:54 ` [dpdk-dev] [PATCH v3 10/12] pmd/nfp: " Jianfeng Tan
2016-02-25 7:54 ` [dpdk-dev] [PATCH v3 11/12] pmd/vmxnet3: " Jianfeng Tan
2016-02-25 7:54 ` [dpdk-dev] [PATCH v3 12/12] examples/l3fwd: add option to parse ptype Jianfeng Tan
2016-02-26 0:04 ` [dpdk-dev] [PATCH v4 00/12] Add API to get packet type info Jianfeng Tan
2016-02-26 0:04 ` [dpdk-dev] [PATCH v4 01/12] ethdev: add API to query packet type filling info Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 00/12] Add API to get packet type info Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 01/12] ethdev: add API to query packet type filling info Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 02/12] pmd/cxgbe: add dev_ptype_info_get implementation Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 03/12] pmd/e1000: " Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 04/12] pmd/enic: " Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 05/12] pmd/fm10k: " Jianfeng Tan
2016-03-02 20:11 ` Chen, Jing D
2016-03-03 6:03 ` Tan, Jianfeng
2016-03-03 15:47 ` Ananyev, Konstantin
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 06/12] pmd/i40e: " Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 07/12] pmd/ixgbe: " Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 08/12] pmd/mlx4: " Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 09/12] pmd/mlx5: " Jianfeng Tan
2016-02-26 8:26 ` Adrien Mazarguil
2016-02-26 8:36 ` Tan, Jianfeng
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 10/12] pmd/nfp: " Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 11/12] pmd/vmxnet3: " Jianfeng Tan
2016-02-26 0:09 ` [dpdk-dev] [PATCH v4 12/12] examples/l3fwd: add option to parse ptype Jianfeng Tan
2016-02-26 13:14 ` Ananyev, Konstantin
2016-02-26 14:21 ` Tan, Jianfeng
2016-02-26 14:27 ` Ananyev, Konstantin
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 00/11] Add API to get packet type info Jianfeng Tan
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 01/11] ethdev: add API to query packet type filling info Jianfeng Tan
2016-02-29 11:34 ` Panu Matilainen
2016-02-29 16:41 ` Tan, Jianfeng
2016-03-01 6:29 ` Panu Matilainen
2016-03-01 7:59 ` Thomas Monjalon
2016-03-01 8:00 ` Tan, Jianfeng
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 02/11] pmd/cxgbe: add dev_ptype_info_get implementation Jianfeng Tan
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 03/11] pmd/e1000: " Jianfeng Tan
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 04/11] pmd/enic: " Jianfeng Tan
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 05/11] pmd/fm10k: " Jianfeng Tan
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 06/11] pmd/i40e: " Jianfeng Tan
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 07/11] pmd/ixgbe: " Jianfeng Tan
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 08/11] pmd/mlx4: " Jianfeng Tan
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 09/11] pmd/mlx5: " Jianfeng Tan
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 10/11] pmd/nfp: " Jianfeng Tan
2016-02-26 7:34 ` [dpdk-dev] [PATCH v5 11/11] pmd/vmxnet3: " Jianfeng Tan
2016-02-29 16:54 ` [dpdk-dev] [PATCH v5 00/11] Add API to get packet type info Ananyev, Konstantin
2016-02-29 17:01 ` Adrien Mazarguil
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 " Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 01/11] ethdev: add API to query packet type filling info Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 02/11] pmd/cxgbe: add dev_ptype_info_get implementation Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 03/11] pmd/e1000: " Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 04/11] pmd/enic: " Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 05/11] pmd/fm10k: " Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 06/11] pmd/i40e: " Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 07/11] pmd/ixgbe: " Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 08/11] pmd/mlx4: " Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 09/11] pmd/mlx5: " Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 10/11] pmd/nfp: " Jianfeng Tan
2016-02-29 20:30 ` [dpdk-dev] [PATCH v6 11/11] pmd/vmxnet3: " Jianfeng Tan
2016-03-01 1:23 ` [dpdk-dev] [PATCH] examples/l3fwd: fix using packet type blindly Jianfeng Tan
2016-03-01 13:51 ` Ananyev, Konstantin
2016-03-01 14:17 ` Tan, Jianfeng
2016-03-01 14:30 ` Ananyev, Konstantin
2016-03-04 8:38 ` [dpdk-dev] [PATCH v2] " Jianfeng Tan
2016-03-07 18:51 ` Ananyev, Konstantin
2016-03-08 17:11 ` Tan, Jianfeng
2016-03-10 5:50 ` [dpdk-dev] [PATCH v3 0/2] " Jianfeng Tan
2016-03-10 5:50 ` [dpdk-dev] [PATCH v3 1/2] " Jianfeng Tan
2016-03-10 5:50 ` [dpdk-dev] [PATCH v3 2/2] config: enable vector driver by default Jianfeng Tan
2016-03-10 14:26 ` [dpdk-dev] [PATCH v3 0/2] examples/l3fwd: fix using packet type blindly Ananyev, Konstantin
2016-03-25 0:47 ` [dpdk-dev] [PATCH v4 0/3] packet type Jianfeng Tan
2016-03-25 0:47 ` [dpdk-dev] [PATCH v4 1/3] ethdev: refine API to query supported packet types Jianfeng Tan
2016-03-25 3:15 ` [dpdk-dev] [PATCH 0/2] ethdev: refine new API to query supported ptypes Jianfeng Tan
2016-03-25 3:15 ` [dpdk-dev] [PATCH 1/2] " Jianfeng Tan
2016-03-25 3:15 ` [dpdk-dev] [PATCH 2/2] doc: update which PMDs can parse packet type Jianfeng Tan
2016-03-25 14:21 ` Bruce Richardson
2016-03-25 16:10 ` Tan, Jianfeng
2016-04-01 15:55 ` Thomas Monjalon
2016-03-25 10:57 ` [dpdk-dev] [PATCH 0/2] ethdev: refine new API to query supported ptypes Ananyev, Konstantin
2016-04-06 3:51 ` [dpdk-dev] [PATCH v2] " Jianfeng Tan
2016-04-06 14:32 ` Thomas Monjalon
2016-03-25 10:01 ` [dpdk-dev] [PATCH v4 1/3] ethdev: refine API to query supported packet types Tan, Jianfeng
2016-03-25 10:13 ` Bruce Richardson
2016-03-25 0:47 ` [dpdk-dev] [PATCH v4 2/3] examples/l3fwd: fix using packet type blindly Jianfeng Tan
2016-03-25 18:24 ` Thomas Monjalon
2016-03-25 0:47 ` [dpdk-dev] [PATCH v4 3/3] config: enable vector driver by default Jianfeng Tan
2016-03-25 18:34 ` [dpdk-dev] [PATCH v4 0/3] packet type Thomas Monjalon
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 00/11] Add API to get packet type info Jianfeng Tan
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 01/11] ethdev: add API to query packet type filling info Jianfeng Tan
2016-03-10 14:28 ` Bruce Richardson
2016-03-14 9:44 ` Thomas Monjalon
2016-03-14 9:48 ` Bruce Richardson
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 02/11] pmd/cxgbe: add dev_ptype_info_get implementation Jianfeng Tan
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 03/11] pmd/e1000: " Jianfeng Tan
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 04/11] pmd/enic: " Jianfeng Tan
2016-03-10 14:50 ` Bruce Richardson
2016-03-10 14:51 ` Bruce Richardson
2016-03-10 18:23 ` Tan, Jianfeng
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 05/11] pmd/fm10k: " Jianfeng Tan
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 06/11] pmd/i40e: " Jianfeng Tan
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 07/11] pmd/ixgbe: " Jianfeng Tan
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 08/11] pmd/mlx4: " Jianfeng Tan
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 09/11] pmd/mlx5: " Jianfeng Tan
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 10/11] pmd/nfp: " Jianfeng Tan
2016-03-09 19:31 ` [dpdk-dev] [PATCH v7 11/11] pmd/vmxnet3: " Jianfeng Tan
2016-03-10 14:55 ` [dpdk-dev] [PATCH v7 00/11] Add API to get packet type info Bruce Richardson
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 00/11] Add API to get supported packet types Jianfeng Tan
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 01/11] ethdev: add API to query " Jianfeng Tan
2016-03-14 17:14 ` Ferruh Yigit
2016-03-14 20:50 ` [dpdk-dev] [PATCH v9 " Jianfeng Tan
2016-03-18 9:17 ` Tan, Jianfeng
2016-03-15 1:42 ` [dpdk-dev] [PATCH v8 " Tan, Jianfeng
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 02/11] cxgbe: add dev_supported_ptypes_get implementation Jianfeng Tan
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 03/11] e1000: " Jianfeng Tan
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 04/11] enic: " Jianfeng Tan
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 05/11] fm10k: " Jianfeng Tan
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 06/11] i40e: " Jianfeng Tan
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 07/11] ixgbe: " Jianfeng Tan
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 08/11] mlx4: " Jianfeng Tan
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 09/11] mlx5: " Jianfeng Tan
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 10/11] nfp: " Jianfeng Tan
2016-03-14 7:42 ` [dpdk-dev] [PATCH v8 11/11] vmxnet3: " Jianfeng Tan
2016-03-18 16:21 ` [dpdk-dev] [PATCH v8 00/11] Add API to get supported packet types Bruce Richardson
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=20160106172248.GT12095@6wind.com \
--to=adrien.mazarguil@6wind.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@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).