[dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Jijiang Liu]

The i40e NIC can recognize many packet types, including ordinary L2 packet format and tunneling packet format such as IP in IP, IP in GRE, MAC in GRE and MAC in UDP.

This patch set provides abstract definitions of packet types,
which can help user to use these packet types directly in their applications to speed up receive packet analysis.

Moreover, this patch set translates i40e packet types to abstract packet types in i40e driver,
and make the corresponding changes in test applications.

Jijiang Liu (4):
  Add packet type and IP header check in rte_mbuf 
  Remove the PKT_RX_TUNNEL_IPV4_HDR and the PKT_RX_TUNNEL_IPV6_HDR 
  Translate i40e packet types
  Make the corresponding changes in test-pmd 

 app/test-pmd/csumonly.c         |   12 +-
 app/test-pmd/rxonly.c           |   15 +-
 lib/librte_mbuf/rte_mbuf.h      |  225 ++++++++++++++-
 lib/librte_pmd_i40e/i40e_rxtx.c |  604 +++++++++++++++++++++------------------
 4 files changed, 569 insertions(+), 287 deletions(-)

-- 
1.7.7.6

[dpdk-dev] [PATCH 1/4] rte_mbuf:add packet types

[Jijiang Liu]

This patch abstracts packet types of L2 packet, Non Tunneled IPv4/6, IP in IP, IP in GRE, MAC in GRE and MAC in UDP, and add 4 MACROS to check packet IP header.

Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
 lib/librte_mbuf/rte_mbuf.h |  223 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 223 insertions(+), 0 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index f5f8658..678db0d 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -125,6 +125,229 @@ extern "C" {
  */
 #define PKT_TX_OFFLOAD_MASK (PKT_TX_VLAN_PKT | PKT_TX_IP_CKSUM | PKT_TX_L4_MASK)
 
+/**
+ * Ethernet packet type
+ */
+enum rte_eth_packet_type {
+
+	/* undefined packet type, means HW can't recognise it */
+	RTE_PTYPE_UNDEF = 0,
+
+	/* L2 Packet types */
+	RTE_PTYPE_PAY2,
+	RTE_PTYPE_TimeSync_PAY2, /**< IEEE1588 and 802.1AS */
+	RTE_PTYPE_FIP_PAY2,      /**< FCoE Initiation Protocol */
+	RTE_PTYPE_LLDP_PAY2,     /**< Link Layer Discovery Protocol */
+	RTE_PTYPE_ECP_PAY2,      /**< Edge Control Protocol */
+	RTE_PTYPE_EAPOL_PAY2,
+	/**< IEEE 802.1X Extensible Authentication Protocol over LAN */
+	RTE_PTYPE_ARP,
+	RTE_PTYPE_FCOE_PAY3,
+	RTE_PTYPE_FCOE_FCDATA,
+	RTE_PTYPE_FCOE_FCRDY,
+	RTE_PTYPE_FCOE_FCRSP,
+	RTE_PTYPE_FCOE_FCOTHER,
+	RTE_PTYPE_FCOE_VFT,
+	RTE_PTYPE_FCOE_VFT_FCDATA,
+	RTE_PTYPE_FCOE_VFT_FCRDY,
+	RTE_PTYPE_FCOE_VFT_FCRSP,
+	RTE_PTYPE_FCOE_VFT_FCOTHER,
+
+	/* Non Tunneled IPv4 */
+	RTE_PTYPE_IPv4FRAG,
+	RTE_PTYPE_IPv4,
+	RTE_PTYPE_IPv4_UDP,
+	RTE_PTYPE_IPv4_TCP,
+	RTE_PTYPE_IPv4_SCTP,
+	RTE_PTYPE_IPv4_ICMP,
+
+	/* IP in IP Tunneling (IPv4 --> IPv4) */
+	RTE_PTYPE_IPv4_IPv4FRAG,
+	RTE_PTYPE_IPv4_IPv4,
+	RTE_PTYPE_IPv4_IPv4_UDP,
+	RTE_PTYPE_IPv4_IPv4_TCP,
+	RTE_PTYPE_IPv4_IPv4_SCTP,
+	RTE_PTYPE_IPv4_IPv4_ICMP,
+
+	/* IP in IP Tunneling (IPv4 --> IPv6) */
+	RTE_PTYPE_IPv4_IPv6FRAG,
+	RTE_PTYPE_IPv4_IPv6,
+	RTE_PTYPE_IPv4_IPv6_UDP,
+	RTE_PTYPE_IPv4_IPv6_TCP,
+	RTE_PTYPE_IPv4_IPv6_SCTP,
+	RTE_PTYPE_IPv4_IPv6_ICMP,
+
+	/* IPv4 --> GRE/Teredo/VXLAN */
+	RTE_PTYPE_IPv4_GRENAT_PAY3,
+
+	/* IPv4 --> GRE/Teredo/VXLAN --> IPv4 */
+	RTE_PTYPE_IPv4_GRENAT_IPv4FRAG,
+	RTE_PTYPE_IPv4_GRENAT_IPv4,
+	RTE_PTYPE_IPv4_GRENAT_IPv4_UDP,
+	RTE_PTYPE_IPv4_GRENAT_IPv4_TCP,
+	RTE_PTYPE_IPv4_GRENAT_IPv4_SCTP,
+	RTE_PTYPE_IPv4_GRENAT_IPv4_ICMP,
+
+	/* IPv4 --> GRE/Teredo/VXLAN --> IPv6 */
+	RTE_PTYPE_IPv4_GRENAT_IPv6FRAG,
+	RTE_PTYPE_IPv4_GRENAT_IPv6,
+	RTE_PTYPE_IPv4_GRENAT_IPv6_UDP,
+	RTE_PTYPE_IPv4_GRENAT_IPv6_TCP,
+	RTE_PTYPE_IPv4_GRENAT_IPv6_SCTP,
+	RTE_PTYPE_IPv4_GRENAT_IPv6_ICMP,
+
+	/* IPv4 --> GRE/Teredo/VXLAN --> MAC */
+	RTE_PTYPE_IPv4_GRENAT_MAC_PAY3,
+
+	/* IPv4 --> GRE/Teredo/VXLAN --> MAC --> IPv4 */
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv4FRAG,
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv4,
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv4_UDP,
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv4_TCP,
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv4_SCTP,
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv4_ICMP,
+
+	/* IPv4 --> GRE/Teredo/VXLAN --> MAC --> IPv6 */
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv6FRAG,
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv6,
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv6_UDP,
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv6_TCP,
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv6_SCTP,
+	RTE_PTYPE_IPv4_GRENAT_MAC_IPv6_ICMP,
+
+	/* IPv4 --> GRE/Teredo/VXLAN --> MAC/VLAN */
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_PAY3,
+
+	/* IPv4 --> GRE/Teredo/VXLAN --> MAC/VLAN --> IPv4 */
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4FRAG,
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4,
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4_UDP,
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4_TCP,
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4_SCTP,
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4_ICMP,
+
+	/* IPv4 --> GRE/Teredo/VXLAN --> MAC/VLAN --> IPv6 */
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6FRAG,
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6,
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_UDP,
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_TCP,
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_SCTP,
+	RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_ICMP,
+
+	/* Non Tunneled IPv6 */
+	RTE_PTYPE_IPv6FRAG,
+	RTE_PTYPE_IPv6,
+	RTE_PTYPE_IPv6_UDP,
+	RTE_PTYPE_IPv6_TCP,
+	RTE_PTYPE_IPv6_SCTP,
+	RTE_PTYPE_IPv6_ICMP,
+
+	/* IP in IP Tunneling (IPv6 --> IPv4) */
+	RTE_PTYPE_IPv6_IPv4FRAG,
+	RTE_PTYPE_IPv6_IPv4,
+	RTE_PTYPE_IPv6_IPv4_UDP,
+	RTE_PTYPE_IPv6_IPv4_TCP,
+	RTE_PTYPE_IPv6_IPv4_SCTP,
+	RTE_PTYPE_IPv6_IPv4_ICMP,
+
+	/* IP in IP Tunneling (IPv6 --> IPv6) */
+	RTE_PTYPE_IPv6_IPv6FRAG,
+	RTE_PTYPE_IPv6_IPv6,
+	RTE_PTYPE_IPv6_IPv6_UDP,
+	RTE_PTYPE_IPv6_IPv6_TCP,
+	RTE_PTYPE_IPv6_IPv6_SCTP,
+	RTE_PTYPE_IPv6_IPv6_ICMP,
+
+	/* IPv6 --> GRE/Teredo/VXLAN */
+	RTE_PTYPE_IPv6_GRENAT_PAY3,
+
+	/* IPv6 --> GRE/Teredo/VXLAN --> IPv4 */
+	RTE_PTYPE_IPv6_GRENAT_IPv4FRAG,
+	RTE_PTYPE_IPv6_GRENAT_IPv4,
+	RTE_PTYPE_IPv6_GRENAT_IPv4_UDP,
+	RTE_PTYPE_IPv6_GRENAT_IPv4_TCP,
+	RTE_PTYPE_IPv6_GRENAT_IPv4_SCTP,
+	RTE_PTYPE_IPv6_GRENAT_IPv4_ICMP,
+
+	/* IPv6 --> GRE/Teredo/VXLAN --> IPv6 */
+	RTE_PTYPE_IPv6_GRENAT_IPv6FRAG,
+	RTE_PTYPE_IPv6_GRENAT_IPv6,
+	RTE_PTYPE_IPv6_GRENAT_IPv6_UDP,
+	RTE_PTYPE_IPv6_GRENAT_IPv6_TCP,
+	RTE_PTYPE_IPv6_GRENAT_IPv6_SCTP,
+	RTE_PTYPE_IPv6_GRENAT_IPv6_ICMP,
+
+	/* IPv6 --> GRE/Teredo/VXLAN --> MAC */
+	RTE_PTYPE_IPv6_GRENAT_MAC_PAY3,
+
+	/* IPv6 --> GRE/Teredo/VXLAN --> MAC --> IPv4 */
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv4FRAG,
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv4,
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv4_UDP,
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv4_TCP,
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv4_SCTP,
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv4_ICMP,
+
+	/* IPv6 --> GRE/Teredo/VXLAN --> MAC --> IPv6 */
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv6FRAG,
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv6,
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv6_UDP,
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv6_TCP,
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv6_SCTP,
+	RTE_PTYPE_IPv6_GRENAT_MAC_IPv6_ICMP,
+
+	/* IPv6 --> GRE/Teredo/VXLAN --> MAC/VLAN */
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_PAY3,
+
+	/* IPv6 --> GRE/Teredo/VXLAN --> MAC/VLAN --> IPv4 */
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4FRAG,
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4,
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4_UDP,
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4_TCP,
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4_SCTP,
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4_ICMP,
+
+	/* IPv6 --> GRE/Teredo/VXLAN --> MAC/VLAN --> IPv6 */
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6FRAG,
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6,
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6_UDP,
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6_TCP,
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6_SCTP,
+	RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6_ICMP,
+};
+
+/**
+ * Given the packet type returns if it is a packet with IPv4 header,
+ * which includes IPv4 tunneling.
+ */
+#define RTE_ETH_IS_IPV4_HDR(ptype) \
+	((ptype >= RTE_PTYPE_IPv4FRAG) && \
+	(ptype <= RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_ICMP))
+
+/**
+ * Given the packet type returns if it is a tunneling packet
+ * with IPv4 header.
+ */
+#define RTE_ETH_IS_TUNNEL_IPV4_HDR(ptype) \
+	((ptype >= RTE_PTYPE_IPv4FRAG) && \
+	(ptype <= RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_ICMP))
+
+/**
+ * Given the packet type returns if it is a packet with IPv6 header,
+ * which includes IPv6 tunneling.
+ */
+#define RTE_ETH_IS_IPV6_HDR(ptype) \
+	((ptype >= RTE_PTYPE_IPv6FRAG) && \
+	(ptype <= RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6_ICMP))
+
+/**
+ * Given the packet type returns if it is a tunneling packet with
+ * IPv6 header
+ */
+#define RTE_ETH_IS_TUNNEL_IPV6_HDR(ptype) \
+	((ptype >= RTE_PTYPE_IPv6_IPv4FRAG) && \
+	(ptype <= RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6_ICMP))
+
 /* define a set of marker types that can be used to refer to set points in the
  * mbuf */
 typedef void    *MARKER[0];   /**< generic marker for a point in a structure */
-- 
1.7.7.6

Re: [dpdk-dev] [PATCH 1/4] rte_mbuf:add packet types

[Olivier MATZ]

Hi Jijiang,

On 11/18/2014 08:37 AM, Jijiang Liu wrote:
> This patch abstracts packet types of L2 packet, Non Tunneled IPv4/6, IP in IP, IP in GRE, MAC in GRE and MAC in UDP, and add 4 MACROS to check packet IP header.
>
> Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
> ---
>   lib/librte_mbuf/rte_mbuf.h |  223 ++++++++++++++++++++++++++++++++++++++++++++
>   1 files changed, 223 insertions(+), 0 deletions(-)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index f5f8658..678db0d 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -125,6 +125,229 @@ extern "C" {
>    */
>   #define PKT_TX_OFFLOAD_MASK (PKT_TX_VLAN_PKT | PKT_TX_IP_CKSUM | PKT_TX_L4_MASK)
>
> +/**
> + * Ethernet packet type
> + */
> +enum rte_eth_packet_type {
> +
> +	/* undefined packet type, means HW can't recognise it */
> +	RTE_PTYPE_UNDEF = 0,
> +
> +	/* L2 Packet types */
> +	RTE_PTYPE_PAY2,
> +	RTE_PTYPE_TimeSync_PAY2, /**< IEEE1588 and 802.1AS */
> +	RTE_PTYPE_FIP_PAY2,      /**< FCoE Initiation Protocol */
> +	RTE_PTYPE_LLDP_PAY2,     /**< Link Layer Discovery Protocol */
> +	RTE_PTYPE_ECP_PAY2,      /**< Edge Control Protocol */
> [...]

I have one question about the packet_type: it is not clear to me
what the software can expect, for instance when RTE_PTYPE_IPv4_IPv4
is set. What does that mean exactly? Which fields must be valid in
the packet to have this type?
- L2 ethertype
- Presence of vlan?
- IP version
- IP checksum
- IP header length
- IP length (compared to packet len)
- anything about IP options?

This question applies to all types of course.

If I want to use packet type in an IP stack, I need to know which
fields are checked by hardware (and what "checked" means for some of
them), so I can do the remaining work in my application.

If I want to write a new PMD (maybe a virtual one, full software), what
do I need to check in the packet if I want to set the
RTE_PTYPE_IPv4_IPv4 type?

I also feel it can be redundant with the current flags ("header is IPv4"
for instance).

To me, these types look very "i40e" oriented. If tomorrow (or today ?)
we want to write a PMD for a hardware that is able to recognize IPv4,
but does not do exactly the same checks than i40e. It is crucial that
what having a packet type set means... else it will stay an i40e-only
mbuf field, which is probably not what we want.

So, I think if we really want packet types to be integrated in mbuf, we 
need to:
- start with a small list (maybe ipv4, ipv6, vxlan tunnels, ...)
- each type must be well defined: what does having this type means? We
   *need* to know what was checked by the hw.
- remove similar things in ol_flags to avoid having a redundant API.

Regards,
Olivier

Re: [dpdk-dev] [PATCH 1/4] rte_mbuf:add packet types

[Liu, Jijiang]

Hi Olivier,


> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Wednesday, November 19, 2014 6:39 PM
> To: Liu, Jijiang; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/4] rte_mbuf:add packet types
> 
> Hi Jijiang,
> 
> On 11/18/2014 08:37 AM, Jijiang Liu wrote:
> > This patch abstracts packet types of L2 packet, Non Tunneled IPv4/6, IP in IP, IP
> in GRE, MAC in GRE and MAC in UDP, and add 4 MACROS to check packet IP
> header.
> >
> > Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
> > ---
> >   lib/librte_mbuf/rte_mbuf.h |  223
> ++++++++++++++++++++++++++++++++++++++++++++
> >   1 files changed, 223 insertions(+), 0 deletions(-)
> >
> > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > index f5f8658..678db0d 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -125,6 +125,229 @@ extern "C" {
> >    */
> >   #define PKT_TX_OFFLOAD_MASK (PKT_TX_VLAN_PKT | PKT_TX_IP_CKSUM |
> > PKT_TX_L4_MASK)
> >
> > +/**
> > + * Ethernet packet type
> > + */
> > +enum rte_eth_packet_type {
> > +
> > +	/* undefined packet type, means HW can't recognise it */
> > +	RTE_PTYPE_UNDEF = 0,
> > +
> > +	/* L2 Packet types */
> > +	RTE_PTYPE_PAY2,
> > +	RTE_PTYPE_TimeSync_PAY2, /**< IEEE1588 and 802.1AS */
> > +	RTE_PTYPE_FIP_PAY2,      /**< FCoE Initiation Protocol */
> > +	RTE_PTYPE_LLDP_PAY2,     /**< Link Layer Discovery Protocol */
> > +	RTE_PTYPE_ECP_PAY2,      /**< Edge Control Protocol */
> > [...]
> 
> I have one question about the packet_type: it is not clear to me what the
> software can expect, for instance when RTE_PTYPE_IPv4_IPv4 is set. What does
> that mean exactly? Which fields must be valid in the packet to have this type?
> - L2 ethertype
> - Presence of vlan?
> - IP version
> - IP checksum
> - IP header length
> - IP length (compared to packet len)
> - anything about IP options?
The RTE_PTYPE_IPv4_IPv4 means that packet format is MAC, IPV4, IPV4, PAY3. The following fields are valid,
L2 ethertype
No VLAN
IPv4,

The RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_ICMP means that the packet format is MAC without VLAN, IPv4,GRE or UDP tunneling header, MAC with VLAN, IPv6, ICMP, PAY4
In all the packet types, I omitted MAC part.

> 
> This question applies to all types of course.
> 
> If I want to use packet type in an IP stack, I need to know which fields are
> checked by hardware (and what "checked" means for some of them), so I can do
> the remaining work in my application.
> If I want to write a new PMD (maybe a virtual one, full software), what do I need
> to check in the packet if I want to set the
> RTE_PTYPE_IPv4_IPv4 type?

For RTE_PTYPE_IPv4_IPv4, you just need to check PAY3 directly because you have already known the packet format, so you don't need to check if there is VLAN or IPv6.

I admit that the RTE_PTYPE_IPv4_IPv4 is little i40e specific. It is not standard format.

> I also feel it can be redundant with the current flags ("header is IPv4"
> for instance).

> To me, these types look very "i40e" oriented. If tomorrow (or today ?) we want to
> write a PMD for a hardware that is able to recognize IPv4, but does not do exactly
> the same checks than i40e. It is crucial that what having a packet type set
> means... 

If the packet type can't match these defined packet type, and I think we can add a new packet type in rte_eth_packet_type.

>else it will stay an i40e-only mbuf field, which is probably not what we
> want.
It is open if you don't like which name/definition of the packet types,  I can change it.

> 
> So, I think if we really want packet types to be integrated in mbuf, we need to:
> - start with a small list (maybe ipv4, ipv6, vxlan tunnels, ...).
Ok, makes sense. But a question is how to map i40e paket type if  the packet type is not defined.

For example, if the following packet type are not defined, how to map i40e packet type, we will probably omit these for i40e.
	/* L2 Packet types */
+	RTE_PTYPE_PAY2,
+	RTE_PTYPE_TimeSync_PAY2, /**< IEEE1588 and 802.1AS */
+	RTE_PTYPE_FIP_PAY2,      /**< FCoE Initiation Protocol */
+	RTE_PTYPE_LLDP_PAY2,     /**< Link Layer Discovery Protocol */
+	RTE_PTYPE_ECP_PAY2,      /**< Edge Control Protocol */
+	RTE_PTYPE_EAPOL_PAY2,
+	/**< IEEE 802.1X Extensible Authentication Protocol over LAN */
+	RTE_PTYPE_ARP,
+	RTE_PTYPE_FCOE_PAY3,
+	RTE_PTYPE_FCOE_FCDATA,
+	RTE_PTYPE_FCOE_FCRDY,
+	RTE_PTYPE_FCOE_FCRSP,
+	RTE_PTYPE_FCOE_FCOTHER,
+	RTE_PTYPE_FCOE_VFT,
+	RTE_PTYPE_FCOE_VFT_FCDATA,
+	RTE_PTYPE_FCOE_VFT_FCRDY,
+	RTE_PTYPE_FCOE_VFT_FCRSP,
+	RTE_PTYPE_FCOE_VFT_FCOTHER,
+
> - each type must be well defined: what does having this type means? We
>    *need* to know what was checked by the hw.
Current packet name have already had clear meaning, I thought.

> - remove similar things in ol_flags to avoid having a redundant API.

Yes, when all i40e/ixgbe/igb PMDs done, the related IP header offload should be removed.
 I just changed for i40e, there still are igb&ixgbe need to be changed in DPDK2.0, so we can't remove the IP ol_flags now.

Actually, I think it will be a good time to integrate all the changes for packet type when all the PMDs done in DPDK2.0.
 Thomas, do you agree on this?

> 
> Regards,
> Olivier

Re: [dpdk-dev] [PATCH 1/4] rte_mbuf:add packet types

[Olivier MATZ]

Hello Jijiang,

On 11/21/2014 01:26 PM, Liu, Jijiang wrote:
>> I have one question about the packet_type: it is not clear to me what the
>> software can expect, for instance when RTE_PTYPE_IPv4_IPv4 is set. What does
>> that mean exactly? Which fields must be valid in the packet to have this type?
>> - L2 ethertype
>> - Presence of vlan?
>> - IP version
>> - IP checksum
>> - IP header length
>> - IP length (compared to packet len)
>> - anything about IP options?
> The RTE_PTYPE_IPv4_IPv4 means that packet format is MAC, IPV4, IPV4, PAY3. The following fields are valid,
> L2 ethertype
> No VLAN
> IPv4,

OK. But IPv4 is not a field, it's a header composed of several fields.
When a network stack receives a packet, it checks the validity of the
IPv4 fields. The offload flags helps the application to avoid doing
some checks, that's why it's important to know what the hardware
already verified when a flag is set.

Here is a example of what the application may check. Knowing the
meaning of the flag is having an answer to these questions. I probably
forgot some, but I think you get the point.


When RTE_PTYPE_IPv4 is set does it mean that IP.version is 4?

When RTE_PTYPE_IPv4 is set does it mean that IP.ihl is not smaller
than 5?

When RTE_PTYPE_IPv4 is set does it mean that IP.ihl is not higher
than 15?

When RTE_PTYPE_IPv4 is set does it mean that IP.checksum is
verified?

When RTE_PTYPE_IPv4 is set does it mean that IP.total_len is
not lower than 20?

When RTE_PTYPE_IPv4 is set does it mean that IP.total_len is
not higher than m_len(m) + 14?

When RTE_PTYPE_IPv4 is set does it mean that IP.total_len is
not lower than m_len(m) + 14? (there is a trap here)

When RTE_PTYPE_IPv4 is set does it mean that (IP.flags & 1) is 0?

When RTE_PTYPE_IPv4 is set does it mean that IP.offset is lower
than 65528?

When RTE_PTYPE_IPv4 is set, can the packet be a fragment?

When RTE_PTYPE_IPv4 is set does it mean that there is no options?

Any condition on source/dest address?


The same questions (but adapted to the protocol) could be asked for
any packet type, that was just an example.

>> - remove similar things in ol_flags to avoid having a redundant API.
> 
> Yes, when all i40e/ixgbe/igb PMDs done, the related IP header offload should be removed.
>  I just changed for i40e, there still are igb&ixgbe need to be changed in DPDK2.0, so we can't remove the IP ol_flags now.

How can an application deal with 2 different APIs ?
The application should work with any driver. It can have a i40e
interface and an ixgbe interface at the same time.


Regards,
Olivier

[dpdk-dev] [PATCH 2/4] rte_mbuf:remove tunneling IP offload flags

[Jijiang Liu]

The PKT_RX_TUNNEL_IPV4_HDR and the PKT_RX_TUNNEL_IPV6_HDR are removed, they are useless now.

Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
 lib/librte_mbuf/rte_mbuf.h |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 678db0d..d0d395c 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -91,8 +91,6 @@ extern "C" {
 #define PKT_RX_IPV6_HDR_EXT  (1ULL << 8)  /**< RX packet with extended IPv6 header. */
 #define PKT_RX_IEEE1588_PTP  (1ULL << 9)  /**< RX IEEE1588 L2 Ethernet PT Packet. */
 #define PKT_RX_IEEE1588_TMST (1ULL << 10) /**< RX IEEE1588 L2/L4 timestamped packet.*/
-#define PKT_RX_TUNNEL_IPV4_HDR (1ULL << 11) /**< RX tunnel packet with IPv4 header.*/
-#define PKT_RX_TUNNEL_IPV6_HDR (1ULL << 12) /**< RX tunnel packet with IPv6 header. */
 
 #define PKT_TX_VLAN_PKT      (1ULL << 55) /**< TX packet is a 802.1q VLAN packet. */
 #define PKT_TX_IP_CKSUM      (1ULL << 54) /**< IP cksum of TX pkt. computed by NIC. */
-- 
1.7.7.6

[dpdk-dev] [PATCH 3/4] i40e:translate i40e packet types

[Jijiang Liu]

Translate i40e packet types to abstract packet types, and keep the usage of the PKT_RX_IPV4_HDR and the PKT_RX_IPV4_HDR as before in i40e driver.

Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
 lib/librte_pmd_i40e/i40e_rxtx.c |  604 +++++++++++++++++++++------------------
 1 files changed, 332 insertions(+), 272 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
index 487591d..80f1bc0 100644
--- a/lib/librte_pmd_i40e/i40e_rxtx.c
+++ b/lib/librte_pmd_i40e/i40e_rxtx.c
@@ -142,272 +142,320 @@ i40e_rxd_error_to_pkt_flags(uint64_t qword)
 	return flags;
 }
 
-/* Translate pkt types to pkt flags */
-static inline uint64_t
-i40e_rxd_ptype_to_pkt_flags(uint64_t qword)
+static inline enum rte_eth_packet_type
+i40e_rxd_ptype_mapping(uint64_t qword)
 {
 	uint8_t ptype = (uint8_t)((qword & I40E_RXD_QW1_PTYPE_MASK) >>
 					I40E_RXD_QW1_PTYPE_SHIFT);
-	static const uint64_t ip_ptype_map[I40E_MAX_PKT_TYPE] = {
-		0, /* PTYPE 0 */
-		0, /* PTYPE 1 */
-		0, /* PTYPE 2 */
-		0, /* PTYPE 3 */
-		0, /* PTYPE 4 */
-		0, /* PTYPE 5 */
-		0, /* PTYPE 6 */
-		0, /* PTYPE 7 */
-		0, /* PTYPE 8 */
-		0, /* PTYPE 9 */
-		0, /* PTYPE 10 */
-		0, /* PTYPE 11 */
-		0, /* PTYPE 12 */
-		0, /* PTYPE 13 */
-		0, /* PTYPE 14 */
-		0, /* PTYPE 15 */
-		0, /* PTYPE 16 */
-		0, /* PTYPE 17 */
-		0, /* PTYPE 18 */
-		0, /* PTYPE 19 */
-		0, /* PTYPE 20 */
-		0, /* PTYPE 21 */
-		PKT_RX_IPV4_HDR, /* PTYPE 22 */
-		PKT_RX_IPV4_HDR, /* PTYPE 23 */
-		PKT_RX_IPV4_HDR, /* PTYPE 24 */
-		0, /* PTYPE 25 */
-		PKT_RX_IPV4_HDR, /* PTYPE 26 */
-		PKT_RX_IPV4_HDR, /* PTYPE 27 */
-		PKT_RX_IPV4_HDR, /* PTYPE 28 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 29 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 30 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 31 */
-		0, /* PTYPE 32 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 33 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 34 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 35 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 36 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 37 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 38 */
-		0, /* PTYPE 39 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 40 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 41 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 42 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 43 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 44 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 45 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 46 */
-		0, /* PTYPE 47 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 48 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 49 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 50 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 51 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 52 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 53 */
-		0, /* PTYPE 54 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 55 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 56 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 57 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 58 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 59 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 60 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 61 */
-		0, /* PTYPE 62 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 63 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 64 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 65 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 66 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 67 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 68 */
-		0, /* PTYPE 69 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 70 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 71 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 72 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 73 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 74 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 75 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 76 */
-		0, /* PTYPE 77 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 78 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 79 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 80 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 81 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 82 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 83 */
-		0, /* PTYPE 84 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 85 */
-		PKT_RX_TUNNEL_IPV4_HDR, /* PTYPE 86 */
-		PKT_RX_IPV4_HDR_EXT, /* PTYPE 87 */
-		PKT_RX_IPV6_HDR, /* PTYPE 88 */
-		PKT_RX_IPV6_HDR, /* PTYPE 89 */
-		PKT_RX_IPV6_HDR, /* PTYPE 90 */
-		0, /* PTYPE 91 */
-		PKT_RX_IPV6_HDR, /* PTYPE 92 */
-		PKT_RX_IPV6_HDR, /* PTYPE 93 */
-		PKT_RX_IPV6_HDR, /* PTYPE 94 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 95 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 96 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 97 */
-		0, /* PTYPE 98 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 99 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 100 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 101 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 102 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 103 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 104 */
-		0, /* PTYPE 105 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 106 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 107 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 108 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 109 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 110 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 111 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 112 */
-		0, /* PTYPE 113 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 114 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 115 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 116 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 117 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 118 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 119 */
-		0, /* PTYPE 120 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 121 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 122 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 123 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 124 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 125 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 126 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 127 */
-		0, /* PTYPE 128 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 129 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 130 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 131 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 132 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 133 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 134 */
-		0, /* PTYPE 135 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 136 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 137 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 138 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 139 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 140 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 141 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 142 */
-		0, /* PTYPE 143 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 144 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 145 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 146 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 147 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 148 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 149 */
-		0, /* PTYPE 150 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 151 */
-		PKT_RX_TUNNEL_IPV6_HDR, /* PTYPE 152 */
-		PKT_RX_IPV6_HDR_EXT, /* PTYPE 153 */
-		0, /* PTYPE 154 */
-		0, /* PTYPE 155 */
-		0, /* PTYPE 156 */
-		0, /* PTYPE 157 */
-		0, /* PTYPE 158 */
-		0, /* PTYPE 159 */
-		0, /* PTYPE 160 */
-		0, /* PTYPE 161 */
-		0, /* PTYPE 162 */
-		0, /* PTYPE 163 */
-		0, /* PTYPE 164 */
-		0, /* PTYPE 165 */
-		0, /* PTYPE 166 */
-		0, /* PTYPE 167 */
-		0, /* PTYPE 168 */
-		0, /* PTYPE 169 */
-		0, /* PTYPE 170 */
-		0, /* PTYPE 171 */
-		0, /* PTYPE 172 */
-		0, /* PTYPE 173 */
-		0, /* PTYPE 174 */
-		0, /* PTYPE 175 */
-		0, /* PTYPE 176 */
-		0, /* PTYPE 177 */
-		0, /* PTYPE 178 */
-		0, /* PTYPE 179 */
-		0, /* PTYPE 180 */
-		0, /* PTYPE 181 */
-		0, /* PTYPE 182 */
-		0, /* PTYPE 183 */
-		0, /* PTYPE 184 */
-		0, /* PTYPE 185 */
-		0, /* PTYPE 186 */
-		0, /* PTYPE 187 */
-		0, /* PTYPE 188 */
-		0, /* PTYPE 189 */
-		0, /* PTYPE 190 */
-		0, /* PTYPE 191 */
-		0, /* PTYPE 192 */
-		0, /* PTYPE 193 */
-		0, /* PTYPE 194 */
-		0, /* PTYPE 195 */
-		0, /* PTYPE 196 */
-		0, /* PTYPE 197 */
-		0, /* PTYPE 198 */
-		0, /* PTYPE 199 */
-		0, /* PTYPE 200 */
-		0, /* PTYPE 201 */
-		0, /* PTYPE 202 */
-		0, /* PTYPE 203 */
-		0, /* PTYPE 204 */
-		0, /* PTYPE 205 */
-		0, /* PTYPE 206 */
-		0, /* PTYPE 207 */
-		0, /* PTYPE 208 */
-		0, /* PTYPE 209 */
-		0, /* PTYPE 210 */
-		0, /* PTYPE 211 */
-		0, /* PTYPE 212 */
-		0, /* PTYPE 213 */
-		0, /* PTYPE 214 */
-		0, /* PTYPE 215 */
-		0, /* PTYPE 216 */
-		0, /* PTYPE 217 */
-		0, /* PTYPE 218 */
-		0, /* PTYPE 219 */
-		0, /* PTYPE 220 */
-		0, /* PTYPE 221 */
-		0, /* PTYPE 222 */
-		0, /* PTYPE 223 */
-		0, /* PTYPE 224 */
-		0, /* PTYPE 225 */
-		0, /* PTYPE 226 */
-		0, /* PTYPE 227 */
-		0, /* PTYPE 228 */
-		0, /* PTYPE 229 */
-		0, /* PTYPE 230 */
-		0, /* PTYPE 231 */
-		0, /* PTYPE 232 */
-		0, /* PTYPE 233 */
-		0, /* PTYPE 234 */
-		0, /* PTYPE 235 */
-		0, /* PTYPE 236 */
-		0, /* PTYPE 237 */
-		0, /* PTYPE 238 */
-		0, /* PTYPE 239 */
-		0, /* PTYPE 240 */
-		0, /* PTYPE 241 */
-		0, /* PTYPE 242 */
-		0, /* PTYPE 243 */
-		0, /* PTYPE 244 */
-		0, /* PTYPE 245 */
-		0, /* PTYPE 246 */
-		0, /* PTYPE 247 */
-		0, /* PTYPE 248 */
-		0, /* PTYPE 249 */
-		0, /* PTYPE 250 */
-		0, /* PTYPE 251 */
-		0, /* PTYPE 252 */
-		0, /* PTYPE 253 */
-		0, /* PTYPE 254 */
-		0, /* PTYPE 255 */
+	static const enum rte_eth_packet_type ptype_map[I40E_MAX_PKT_TYPE] = {
+		RTE_PTYPE_UNDEF, /* PTYPE 0 */
+		RTE_PTYPE_PAY2,
+		RTE_PTYPE_TimeSync_PAY2,
+		RTE_PTYPE_FIP_PAY2,
+		RTE_PTYPE_UNDEF, /* PTYPE 4 */
+		RTE_PTYPE_UNDEF, /* PTYPE 5 */
+		RTE_PTYPE_LLDP_PAY2,
+		RTE_PTYPE_ECP_PAY2,
+		RTE_PTYPE_UNDEF, /* PTYPE 8 */
+		RTE_PTYPE_UNDEF, /* PTYPE 9 */
+		RTE_PTYPE_EAPOL_PAY2,
+		RTE_PTYPE_ARP,
+		RTE_PTYPE_FCOE_PAY3,
+		RTE_PTYPE_FCOE_FCDATA,
+		RTE_PTYPE_FCOE_FCRDY,
+		RTE_PTYPE_FCOE_FCRSP,
+		RTE_PTYPE_FCOE_FCOTHER,
+		RTE_PTYPE_FCOE_VFT,
+		RTE_PTYPE_FCOE_VFT_FCDATA,
+		RTE_PTYPE_FCOE_VFT_FCRDY,
+		RTE_PTYPE_FCOE_VFT_FCRSP,
+		RTE_PTYPE_FCOE_VFT_FCOTHER,
+
+		/* Non Tunneled IPv4 */
+		RTE_PTYPE_IPv4FRAG,
+		RTE_PTYPE_IPv4,
+		RTE_PTYPE_IPv4_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 25 */
+		RTE_PTYPE_IPv4_TCP,
+		RTE_PTYPE_IPv4_SCTP,
+		RTE_PTYPE_IPv4_ICMP,
+
+		/* IPv4 --> IPv4 */
+		RTE_PTYPE_IPv4_IPv4FRAG,
+		RTE_PTYPE_IPv4_IPv4,
+		RTE_PTYPE_IPv4_IPv4_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 32 */
+		RTE_PTYPE_IPv4_IPv4_TCP,
+		RTE_PTYPE_IPv4_IPv4_SCTP,
+		RTE_PTYPE_IPv4_IPv4_ICMP,
+
+		/* IPv4 --> IPv6 */
+		RTE_PTYPE_IPv4_IPv6FRAG,
+		RTE_PTYPE_IPv4_IPv6,
+		RTE_PTYPE_IPv4_IPv6_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 39 */
+		RTE_PTYPE_IPv4_IPv6_TCP,
+		RTE_PTYPE_IPv4_IPv6_SCTP,
+		RTE_PTYPE_IPv4_IPv6_ICMP,
+
+		/* IPv4 --> GRE/Teredo/VXLAN */
+		RTE_PTYPE_IPv4_GRENAT_PAY3,
+
+		/* IPv4 --> GRE/Teredo/VXLAN --> IPv4 */
+		RTE_PTYPE_IPv4_GRENAT_IPv4FRAG,
+		RTE_PTYPE_IPv4_GRENAT_IPv4,
+		RTE_PTYPE_IPv4_GRENAT_IPv4_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 47 */
+		RTE_PTYPE_IPv4_GRENAT_IPv4_TCP,
+		RTE_PTYPE_IPv4_GRENAT_IPv4_SCTP,
+		RTE_PTYPE_IPv4_GRENAT_IPv4_ICMP,
+
+		/* IPv4 --> GRE/Teredo/VXLAN --> IPv6 */
+		RTE_PTYPE_IPv4_GRENAT_IPv6FRAG,
+		RTE_PTYPE_IPv4_GRENAT_IPv6,
+		RTE_PTYPE_IPv4_GRENAT_IPv6_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 54 */
+		RTE_PTYPE_IPv4_GRENAT_IPv6_TCP,
+		RTE_PTYPE_IPv4_GRENAT_IPv6_SCTP,
+		RTE_PTYPE_IPv4_GRENAT_IPv6_ICMP,
+
+		/* IPv4 --> GRE/Teredo/VXLAN --> MAC */
+		RTE_PTYPE_IPv4_GRENAT_MAC_PAY3,
+
+		/* IPv4 --> GRE/Teredo/VXLAN --> MAC --> IPv4 */
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv4FRAG,
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv4,
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv4_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 62 */
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv4_TCP,
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv4_SCTP,
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv4_ICMP,
+
+		/* IPv4 --> GRE/Teredo/VXLAN --> MAC --> IPv6 */
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv6FRAG,
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv6,
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv6_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 69 */
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv6_TCP,
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv6_SCTP,
+		RTE_PTYPE_IPv4_GRENAT_MAC_IPv6_ICMP,
+
+		/* IPv4 --> GRE/Teredo/VXLAN --> MAC/VLAN */
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_PAY3,
+
+		/* IPv4 --> GRE/Teredo/VXLAN --> MAC/VLAN --> IPv4 */
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4FRAG,
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4,
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 77 */
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4_TCP,
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4_SCTP,
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv4_ICMP,
+
+		/* IPv4 --> GRE/Teredo/VXLAN --> MAC/VLAN --> IPv6 */
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6FRAG,
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6,
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 84 */
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_TCP,
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_SCTP,
+		RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_ICMP,
+
+		/* Non Tunneled IPv6 */
+		RTE_PTYPE_IPv6FRAG,
+		RTE_PTYPE_IPv6,
+		RTE_PTYPE_IPv6_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 91 */
+		RTE_PTYPE_IPv6_TCP,
+		RTE_PTYPE_IPv6_SCTP,
+		RTE_PTYPE_IPv6_ICMP,
+
+		/* IPv6 --> IPv4 */
+		RTE_PTYPE_IPv6_IPv4FRAG,
+		RTE_PTYPE_IPv6_IPv4,
+		RTE_PTYPE_IPv6_IPv4_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 98 */
+		RTE_PTYPE_IPv6_IPv4_TCP,
+		RTE_PTYPE_IPv6_IPv4_SCTP,
+		RTE_PTYPE_IPv6_IPv4_ICMP,
+
+		/* IPv6 --> IPv6 */
+		RTE_PTYPE_IPv6_IPv6FRAG,
+		RTE_PTYPE_IPv6_IPv6,
+		RTE_PTYPE_IPv6_IPv6_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 105 */
+		RTE_PTYPE_IPv6_IPv6_TCP,
+		RTE_PTYPE_IPv6_IPv6_SCTP,
+		RTE_PTYPE_IPv6_IPv6_ICMP,
+
+		/* IPv6 --> GRE/Teredo/VXLAN */
+		RTE_PTYPE_IPv6_GRENAT_PAY3,
+
+		/* IPv6 --> GRE/Teredo/VXLAN --> IPv4 */
+		RTE_PTYPE_IPv6_GRENAT_IPv4FRAG,
+		RTE_PTYPE_IPv6_GRENAT_IPv4,
+		RTE_PTYPE_IPv6_GRENAT_IPv4_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 113 */
+		RTE_PTYPE_IPv6_GRENAT_IPv4_TCP,
+		RTE_PTYPE_IPv6_GRENAT_IPv4_SCTP,
+		RTE_PTYPE_IPv6_GRENAT_IPv4_ICMP,
+
+		/* IPv6 --> GRE/Teredo/VXLAN --> IPv6 */
+		RTE_PTYPE_IPv6_GRENAT_IPv6FRAG,
+		RTE_PTYPE_IPv6_GRENAT_IPv6,
+		RTE_PTYPE_IPv6_GRENAT_IPv6_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 120 */
+		RTE_PTYPE_IPv6_GRENAT_IPv6_TCP,
+		RTE_PTYPE_IPv6_GRENAT_IPv6_SCTP,
+		RTE_PTYPE_IPv6_GRENAT_IPv6_ICMP,
+
+		/* IPv6 --> GRE/Teredo/VXLAN --> MAC */
+		RTE_PTYPE_IPv6_GRENAT_MAC_PAY3,
+
+		/* IPv6 --> GRE/Teredo/VXLAN --> MAC --> IPv4 */
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv4FRAG,
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv4,
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv4_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 128 */
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv4_TCP,
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv4_SCTP,
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv4_ICMP,
+
+		/* IPv6 --> GRE/Teredo/VXLAN --> MAC --> IPv6 */
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv6FRAG,
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv6,
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv6_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 135 */
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv6_TCP,
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv6_SCTP,
+		RTE_PTYPE_IPv6_GRENAT_MAC_IPv6_ICMP,
+
+		/* IPv6 --> GRE/Teredo/VXLAN --> MAC/VLAN */
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_PAY3,
+
+		/* IPv6 --> GRE/Teredo/VXLAN --> MAC/VLAN --> IPv4 */
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4FRAG,
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4,
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 143 */
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4_TCP,
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4_SCTP,
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv4_ICMP,
+
+		/* IPv6 --> GRE/Teredo/VXLAN --> MAC/VLAN --> IPv6 */
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6FRAG,
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6,
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6_UDP,
+		RTE_PTYPE_UNDEF, /* PTYPE 150 */
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6_TCP,
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6_SCTP,
+		RTE_PTYPE_IPv6_GRENAT_MACVLAN_IPv6_ICMP,
+
+		RTE_PTYPE_UNDEF, /* PTYPE 154 */
+		RTE_PTYPE_UNDEF, /* PTYPE 155 */
+		RTE_PTYPE_UNDEF, /* PTYPE 156 */
+		RTE_PTYPE_UNDEF, /* PTYPE 157 */
+		RTE_PTYPE_UNDEF, /* PTYPE 158 */
+		RTE_PTYPE_UNDEF, /* PTYPE 159 */
+		RTE_PTYPE_UNDEF, /* PTYPE 160 */
+		RTE_PTYPE_UNDEF, /* PTYPE 161 */
+		RTE_PTYPE_UNDEF, /* PTYPE 162 */
+		RTE_PTYPE_UNDEF, /* PTYPE 163 */
+		RTE_PTYPE_UNDEF, /* PTYPE 164 */
+		RTE_PTYPE_UNDEF, /* PTYPE 165 */
+		RTE_PTYPE_UNDEF, /* PTYPE 166 */
+		RTE_PTYPE_UNDEF, /* PTYPE 167 */
+		RTE_PTYPE_UNDEF, /* PTYPE 168 */
+		RTE_PTYPE_UNDEF, /* PTYPE 169 */
+		RTE_PTYPE_UNDEF, /* PTYPE 170 */
+		RTE_PTYPE_UNDEF, /* PTYPE 171 */
+		RTE_PTYPE_UNDEF, /* PTYPE 172 */
+		RTE_PTYPE_UNDEF, /* PTYPE 173 */
+		RTE_PTYPE_UNDEF, /* PTYPE 174 */
+		RTE_PTYPE_UNDEF, /* PTYPE 175 */
+		RTE_PTYPE_UNDEF, /* PTYPE 176 */
+		RTE_PTYPE_UNDEF, /* PTYPE 177 */
+		RTE_PTYPE_UNDEF, /* PTYPE 178 */
+		RTE_PTYPE_UNDEF, /* PTYPE 179 */
+		RTE_PTYPE_UNDEF, /* PTYPE 180 */
+		RTE_PTYPE_UNDEF, /* PTYPE 181 */
+		RTE_PTYPE_UNDEF, /* PTYPE 182 */
+		RTE_PTYPE_UNDEF, /* PTYPE 183 */
+		RTE_PTYPE_UNDEF, /* PTYPE 184 */
+		RTE_PTYPE_UNDEF, /* PTYPE 185 */
+		RTE_PTYPE_UNDEF, /* PTYPE 186 */
+		RTE_PTYPE_UNDEF, /* PTYPE 187 */
+		RTE_PTYPE_UNDEF, /* PTYPE 188 */
+		RTE_PTYPE_UNDEF, /* PTYPE 189 */
+		RTE_PTYPE_UNDEF, /* PTYPE 190 */
+		RTE_PTYPE_UNDEF, /* PTYPE 191 */
+		RTE_PTYPE_UNDEF, /* PTYPE 192 */
+		RTE_PTYPE_UNDEF, /* PTYPE 193 */
+		RTE_PTYPE_UNDEF, /* PTYPE 194 */
+		RTE_PTYPE_UNDEF, /* PTYPE 195 */
+		RTE_PTYPE_UNDEF, /* PTYPE 196 */
+		RTE_PTYPE_UNDEF, /* PTYPE 197 */
+		RTE_PTYPE_UNDEF, /* PTYPE 198 */
+		RTE_PTYPE_UNDEF, /* PTYPE 199 */
+		RTE_PTYPE_UNDEF, /* PTYPE 200 */
+		RTE_PTYPE_UNDEF, /* PTYPE 201 */
+		RTE_PTYPE_UNDEF, /* PTYPE 202 */
+		RTE_PTYPE_UNDEF, /* PTYPE 203 */
+		RTE_PTYPE_UNDEF, /* PTYPE 204 */
+		RTE_PTYPE_UNDEF, /* PTYPE 205 */
+		RTE_PTYPE_UNDEF, /* PTYPE 206 */
+		RTE_PTYPE_UNDEF, /* PTYPE 207 */
+		RTE_PTYPE_UNDEF, /* PTYPE 208 */
+		RTE_PTYPE_UNDEF, /* PTYPE 209 */
+		RTE_PTYPE_UNDEF, /* PTYPE 210 */
+		RTE_PTYPE_UNDEF, /* PTYPE 211 */
+		RTE_PTYPE_UNDEF, /* PTYPE 212 */
+		RTE_PTYPE_UNDEF, /* PTYPE 213 */
+		RTE_PTYPE_UNDEF, /* PTYPE 214 */
+		RTE_PTYPE_UNDEF, /* PTYPE 215 */
+		RTE_PTYPE_UNDEF, /* PTYPE 216 */
+		RTE_PTYPE_UNDEF, /* PTYPE 217 */
+		RTE_PTYPE_UNDEF, /* PTYPE 218 */
+		RTE_PTYPE_UNDEF, /* PTYPE 219 */
+		RTE_PTYPE_UNDEF, /* PTYPE 220 */
+		RTE_PTYPE_UNDEF, /* PTYPE 221 */
+		RTE_PTYPE_UNDEF, /* PTYPE 222 */
+		RTE_PTYPE_UNDEF, /* PTYPE 223 */
+		RTE_PTYPE_UNDEF, /* PTYPE 224 */
+		RTE_PTYPE_UNDEF, /* PTYPE 225 */
+		RTE_PTYPE_UNDEF, /* PTYPE 226 */
+		RTE_PTYPE_UNDEF, /* PTYPE 227 */
+		RTE_PTYPE_UNDEF, /* PTYPE 228 */
+		RTE_PTYPE_UNDEF, /* PTYPE 229 */
+		RTE_PTYPE_UNDEF, /* PTYPE 230 */
+		RTE_PTYPE_UNDEF, /* PTYPE 231 */
+		RTE_PTYPE_UNDEF, /* PTYPE 232 */
+		RTE_PTYPE_UNDEF, /* PTYPE 233 */
+		RTE_PTYPE_UNDEF, /* PTYPE 234 */
+		RTE_PTYPE_UNDEF, /* PTYPE 235 */
+		RTE_PTYPE_UNDEF, /* PTYPE 236 */
+		RTE_PTYPE_UNDEF, /* PTYPE 237 */
+		RTE_PTYPE_UNDEF, /* PTYPE 238 */
+		RTE_PTYPE_UNDEF, /* PTYPE 239 */
+		RTE_PTYPE_UNDEF, /* PTYPE 240 */
+		RTE_PTYPE_UNDEF, /* PTYPE 241 */
+		RTE_PTYPE_UNDEF, /* PTYPE 242 */
+		RTE_PTYPE_UNDEF, /* PTYPE 243 */
+		RTE_PTYPE_UNDEF, /* PTYPE 244 */
+		RTE_PTYPE_UNDEF, /* PTYPE 245 */
+		RTE_PTYPE_UNDEF, /* PTYPE 246 */
+		RTE_PTYPE_UNDEF, /* PTYPE 247 */
+		RTE_PTYPE_UNDEF, /* PTYPE 248 */
+		RTE_PTYPE_UNDEF, /* PTYPE 249 */
+		RTE_PTYPE_UNDEF, /* PTYPE 250 */
+		RTE_PTYPE_UNDEF, /* PTYPE 251 */
+		RTE_PTYPE_UNDEF, /* PTYPE 252 */
+		RTE_PTYPE_UNDEF, /* PTYPE 253 */
+		RTE_PTYPE_UNDEF, /* PTYPE 254 */
+		RTE_PTYPE_UNDEF, /* PTYPE 255 */
 	};
 
-	return ip_ptype_map[ptype];
+	return ptype_map[ptype];
 }
 
 static inline void
@@ -605,6 +653,7 @@ i40e_rx_scan_hw_ring(struct i40e_rx_queue *rxq)
 	volatile union i40e_rx_desc *rxdp;
 	struct i40e_rx_entry *rxep;
 	struct rte_mbuf *mb;
+	enum rte_eth_packet_type packet_type;
 	uint16_t pkt_len;
 	uint64_t qword1;
 	uint32_t rx_status;
@@ -660,12 +709,15 @@ i40e_rx_scan_hw_ring(struct i40e_rx_queue *rxq)
 				rxdp[j].wb.qword0.lo_dword.l2tag1) : 0;
 			pkt_flags = i40e_rxd_status_to_pkt_flags(qword1);
 			pkt_flags |= i40e_rxd_error_to_pkt_flags(qword1);
-			pkt_flags |= i40e_rxd_ptype_to_pkt_flags(qword1);
+			packet_type = i40e_rxd_ptype_mapping(qword1);
+			mb->packet_type = (uint16_t) packet_type;
+			if (RTE_ETH_IS_IPV4_HDR(packet_type))
+				pkt_flags |= PKT_RX_IPV4_HDR;
+			else if (RTE_ETH_IS_IPV6_HDR(packet_type))
+				pkt_flags |= PKT_RX_IPV6_HDR;
+
 			mb->ol_flags = pkt_flags;
 
-			mb->packet_type = (uint16_t)((qword1 &
-					I40E_RXD_QW1_PTYPE_MASK) >>
-					I40E_RXD_QW1_PTYPE_SHIFT);
 			if (pkt_flags & PKT_RX_RSS_HASH)
 				mb->hash.rss = rte_le_to_cpu_32(\
 					rxdp->wb.qword0.hi_dword.rss);
@@ -830,6 +882,7 @@ i40e_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
 	struct i40e_rx_entry *rxe;
 	struct rte_mbuf *rxm;
 	struct rte_mbuf *nmb;
+	enum rte_eth_packet_type packet_type;
 	uint16_t nb_rx;
 	uint32_t rx_status;
 	uint64_t qword1;
@@ -900,9 +953,13 @@ i40e_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
 			rte_le_to_cpu_16(rxd.wb.qword0.lo_dword.l2tag1) : 0;
 		pkt_flags = i40e_rxd_status_to_pkt_flags(qword1);
 		pkt_flags |= i40e_rxd_error_to_pkt_flags(qword1);
-		pkt_flags |= i40e_rxd_ptype_to_pkt_flags(qword1);
-		rxm->packet_type = (uint16_t)((qword1 & I40E_RXD_QW1_PTYPE_MASK) >>
-				I40E_RXD_QW1_PTYPE_SHIFT);
+		packet_type = i40e_rxd_ptype_mapping(qword1);
+		rxm->packet_type = (uint16_t)packet_type;
+		if (RTE_ETH_IS_IPV4_HDR(packet_type))
+			pkt_flags |= PKT_RX_IPV4_HDR;
+		else if (RTE_ETH_IS_IPV6_HDR(packet_type))
+			pkt_flags |= PKT_RX_IPV6_HDR;
+
 		rxm->ol_flags = pkt_flags;
 		if (pkt_flags & PKT_RX_RSS_HASH)
 			rxm->hash.rss =
@@ -938,6 +995,7 @@ i40e_recv_scattered_pkts(void *rx_queue,
 	struct i40e_rx_queue *rxq = rx_queue;
 	volatile union i40e_rx_desc *rx_ring = rxq->rx_ring;
 	volatile union i40e_rx_desc *rxdp;
+	enum rte_eth_packet_type packet_type;
 	union i40e_rx_desc rxd;
 	struct i40e_rx_entry *sw_ring = rxq->sw_ring;
 	struct i40e_rx_entry *rxe;
@@ -1056,10 +1114,12 @@ i40e_recv_scattered_pkts(void *rx_queue,
 			rte_le_to_cpu_16(rxd.wb.qword0.lo_dword.l2tag1) : 0;
 		pkt_flags = i40e_rxd_status_to_pkt_flags(qword1);
 		pkt_flags |= i40e_rxd_error_to_pkt_flags(qword1);
-		pkt_flags |= i40e_rxd_ptype_to_pkt_flags(qword1);
-		first_seg->packet_type = (uint16_t)((qword1 &
-					I40E_RXD_QW1_PTYPE_MASK) >>
-					I40E_RXD_QW1_PTYPE_SHIFT);
+		packet_type = i40e_rxd_ptype_mapping(qword1);
+		first_seg->packet_type = (uint16_t) packet_type;
+		if (RTE_ETH_IS_IPV4_HDR(packet_type))
+			pkt_flags |= PKT_RX_IPV4_HDR;
+		else if (RTE_ETH_IS_IPV6_HDR(packet_type))
+			pkt_flags |= PKT_RX_IPV6_HDR;
 		first_seg->ol_flags = pkt_flags;
 		if (pkt_flags & PKT_RX_RSS_HASH)
 			rxm->hash.rss =
-- 
1.7.7.6

[dpdk-dev] [PATCH 4/4] testpmd:application changes

[Jijiang Liu]

Change the codes in testpmd due to introducing abstract packet type.

Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
---
 app/test-pmd/csumonly.c |   12 ++++++------
 app/test-pmd/rxonly.c   |   20 +++++++++-----------
 2 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 8d10bfd..d9948e7 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -219,6 +219,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
 	struct tcp_hdr   *inner_tcp_hdr;
 	struct sctp_hdr  *sctp_hdr;
 	struct sctp_hdr  *inner_sctp_hdr;
+	enum rte_eth_packet_type  packet_type;
 
 	uint16_t nb_rx;
 	uint16_t nb_tx;
@@ -272,11 +273,10 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
 		mb = pkts_burst[i];
 		l2_len  = sizeof(struct ether_hdr);
 		pkt_ol_flags = mb->ol_flags;
+		packet_type = (enum rte_eth_packet_type)mb->packet_type;
 		ol_flags = (pkt_ol_flags & (~PKT_TX_L4_MASK));
-		ipv4_tunnel = (pkt_ol_flags & PKT_RX_TUNNEL_IPV4_HDR) ?
-				1 : 0;
-		ipv6_tunnel = (pkt_ol_flags & PKT_RX_TUNNEL_IPV6_HDR) ?
-				1 : 0;
+		ipv4_tunnel = RTE_ETH_IS_TUNNEL_IPV4_HDR(packet_type);
+		ipv6_tunnel = RTE_ETH_IS_TUNNEL_IPV6_HDR(packet_type);
 		eth_hdr = rte_pktmbuf_mtod(mb, struct ether_hdr *);
 		eth_type = rte_be_to_cpu_16(eth_hdr->ether_type);
 		if (eth_type == ETHER_TYPE_VLAN) {
@@ -309,7 +309,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
 		 *      + ipv4 or ipv6
 		 *      + udp or tcp or sctp or others
 		 */
-		if (pkt_ol_flags & (PKT_RX_IPV4_HDR | PKT_RX_TUNNEL_IPV4_HDR)) {
+		if (pkt_ol_flags & PKT_RX_IPV4_HDR) {
 
 			/* Do not support ipv4 option field */
 			l3_len = sizeof(struct ipv4_hdr) ;
@@ -455,7 +455,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
 				}
 			}
 			/* End of L4 Handling*/
-		} else if (pkt_ol_flags & (PKT_RX_IPV6_HDR | PKT_RX_TUNNEL_IPV6_HDR)) {
+		} else if (pkt_ol_flags & PKT_RX_IPV6_HDR) {
 			ipv6_hdr = (struct ipv6_hdr *) (rte_pktmbuf_mtod(mb,
 					unsigned char *) + l2_len);
 			l3_len = sizeof(struct ipv6_hdr) ;
diff --git a/app/test-pmd/rxonly.c b/app/test-pmd/rxonly.c
index 9ad1df6..3bf1b93 100644
--- a/app/test-pmd/rxonly.c
+++ b/app/test-pmd/rxonly.c
@@ -71,7 +71,7 @@
 
 #include "testpmd.h"
 
-#define MAX_PKT_RX_FLAGS 13
+#define MAX_PKT_RX_FLAGS 11
 static const char *pkt_rx_flag_names[MAX_PKT_RX_FLAGS] = {
 	"VLAN_PKT",
 	"RSS_HASH",
@@ -86,9 +86,6 @@ static const char *pkt_rx_flag_names[MAX_PKT_RX_FLAGS] = {
 
 	"IEEE1588_PTP",
 	"IEEE1588_TMST",
-
-	"TUNNEL_IPV4_HDR",
-	"TUNNEL_IPV6_HDR",
 };
 
 static inline void
@@ -108,11 +105,12 @@ pkt_burst_receive(struct fwd_stream *fs)
 	struct rte_mbuf  *pkts_burst[MAX_PKT_BURST];
 	struct rte_mbuf  *mb;
 	struct ether_hdr *eth_hdr;
+	enum rte_eth_packet_type packet_type;
 	uint16_t eth_type;
 	uint64_t ol_flags;
 	uint16_t nb_rx;
-	uint16_t i, packet_type;
-	uint64_t is_encapsulation;
+	uint16_t i;
+	uint32_t is_encapsulation;
 
 #ifdef RTE_TEST_PMD_RECORD_CORE_CYCLES
 	uint64_t start_tsc;
@@ -154,10 +152,10 @@ pkt_burst_receive(struct fwd_stream *fs)
 		eth_hdr = rte_pktmbuf_mtod(mb, struct ether_hdr *);
 		eth_type = RTE_BE_TO_CPU_16(eth_hdr->ether_type);
 		ol_flags = mb->ol_flags;
-		packet_type = mb->packet_type;
+		packet_type = (enum rte_eth_packet_type)mb->packet_type;
 
-		is_encapsulation = ol_flags & (PKT_RX_TUNNEL_IPV4_HDR |
-				PKT_RX_TUNNEL_IPV6_HDR);
+		is_encapsulation = RTE_ETH_IS_TUNNEL_IPV4_HDR(packet_type) |
+				RTE_ETH_IS_TUNNEL_IPV6_HDR(packet_type);
 
 		print_ether_addr("  src=", &eth_hdr->s_addr);
 		print_ether_addr(" - dst=", &eth_hdr->d_addr);
@@ -186,7 +184,7 @@ pkt_burst_receive(struct fwd_stream *fs)
 			l2_len  = sizeof(struct ether_hdr);
 
 			 /* Do not support ipv4 option field */
-			if (ol_flags & PKT_RX_TUNNEL_IPV4_HDR) {
+			if (RTE_ETH_IS_TUNNEL_IPV4_HDR(packet_type)) {
 				l3_len = sizeof(struct ipv4_hdr);
 				ipv4_hdr = (struct ipv4_hdr *) (rte_pktmbuf_mtod(mb,
 						unsigned char *) + l2_len);
@@ -207,7 +205,7 @@ pkt_burst_receive(struct fwd_stream *fs)
 
 				printf(" - VXLAN packet: packet type =%d, "
 					"Destination UDP port =%d, VNI = %d",
-					packet_type, RTE_BE_TO_CPU_16(udp_hdr->dst_port),
+					(uint16_t)packet_type, RTE_BE_TO_CPU_16(udp_hdr->dst_port),
 					rte_be_to_cpu_32(vxlan_hdr->vx_vni) >> 8);
 			}
 		}
-- 
1.7.7.6

Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Ananyev, Konstantin]

Hi Frank,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> Sent: Tuesday, November 18, 2014 7:37 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> 
> The i40e NIC can recognize many packet types, including ordinary L2 packet format and tunneling packet format such as IP in IP, IP in
> GRE, MAC in GRE and MAC in UDP.
> 
> This patch set provides abstract definitions of packet types,
> which can help user to use these packet types directly in their applications to speed up receive packet analysis.
> 
> Moreover, this patch set translates i40e packet types to abstract packet types in i40e driver,
> and make the corresponding changes in test applications.
> 
> Jijiang Liu (4):
>   Add packet type and IP header check in rte_mbuf
>   Remove the PKT_RX_TUNNEL_IPV4_HDR and the PKT_RX_TUNNEL_IPV6_HDR
>   Translate i40e packet types
>   Make the corresponding changes in test-pmd
> 
>  app/test-pmd/csumonly.c         |   12 +-
>  app/test-pmd/rxonly.c           |   15 +-
>  lib/librte_mbuf/rte_mbuf.h      |  225 ++++++++++++++-
>  lib/librte_pmd_i40e/i40e_rxtx.c |  604 +++++++++++++++++++++------------------
>  4 files changed, 569 insertions(+), 287 deletions(-)
> 

The patch looks good to me in general.
Though I think it is not complete: we need to make sure that all PMDs RX functions will set mbuf's packet_type
to the defined value.
As right now, only i40e implementation can distinguish packet_type properly, I think all other PMDs
for the freshly received packet should do:
mbuf->packet_type = RTE_PTYPE_UNDEF;    

Another thing: right now mbuf's packet_type is uint16_t.
While enum rte_eth_packet_type will be interpreted by the compiler as 'int' (32bits).
We can either change enum to a lot of defines (which I don't really like to do) or probably just
add a comment somewhere that enum rte_eth_packet_type  should never exceed UINT16_MAX value?

Konstantin

> --
> 1.7.7.6

Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Bruce Richardson]

On Tue, Nov 18, 2014 at 11:33:24AM +0000, Ananyev, Konstantin wrote:
> Hi Frank,
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> > Sent: Tuesday, November 18, 2014 7:37 AM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > 
> > The i40e NIC can recognize many packet types, including ordinary L2 packet format and tunneling packet format such as IP in IP, IP in
> > GRE, MAC in GRE and MAC in UDP.
> > 
> > This patch set provides abstract definitions of packet types,
> > which can help user to use these packet types directly in their applications to speed up receive packet analysis.
> > 
> > Moreover, this patch set translates i40e packet types to abstract packet types in i40e driver,
> > and make the corresponding changes in test applications.
> > 
> > Jijiang Liu (4):
> >   Add packet type and IP header check in rte_mbuf
> >   Remove the PKT_RX_TUNNEL_IPV4_HDR and the PKT_RX_TUNNEL_IPV6_HDR
> >   Translate i40e packet types
> >   Make the corresponding changes in test-pmd
> > 
> >  app/test-pmd/csumonly.c         |   12 +-
> >  app/test-pmd/rxonly.c           |   15 +-
> >  lib/librte_mbuf/rte_mbuf.h      |  225 ++++++++++++++-
> >  lib/librte_pmd_i40e/i40e_rxtx.c |  604 +++++++++++++++++++++------------------
> >  4 files changed, 569 insertions(+), 287 deletions(-)
> > 
> 
> The patch looks good to me in general.
> Though I think it is not complete: we need to make sure that all PMDs RX functions will set mbuf's packet_type
> to the defined value.
> As right now, only i40e implementation can distinguish packet_type properly, I think all other PMDs
> for the freshly received packet should do:
> mbuf->packet_type = RTE_PTYPE_UNDEF;    
> 
> Another thing: right now mbuf's packet_type is uint16_t.
> While enum rte_eth_packet_type will be interpreted by the compiler as 'int' (32bits).
> We can either change enum to a lot of defines (which I don't really like to do) or probably just
> add a comment somewhere that enum rte_eth_packet_type  should never exceed UINT16_MAX value?
>
Add a RTE_PTYPE_MAX value = UINT16_MAX to the enum, perhaps?

/Bruce

Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Ananyev, Konstantin]

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Tuesday, November 18, 2014 1:08 PM
> To: Ananyev, Konstantin
> Cc: Liu, Jijiang; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> 
> On Tue, Nov 18, 2014 at 11:33:24AM +0000, Ananyev, Konstantin wrote:
> > Hi Frank,
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> > > Sent: Tuesday, November 18, 2014 7:37 AM
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > >
> > > The i40e NIC can recognize many packet types, including ordinary L2 packet format and tunneling packet format such as IP in IP, IP
> in
> > > GRE, MAC in GRE and MAC in UDP.
> > >
> > > This patch set provides abstract definitions of packet types,
> > > which can help user to use these packet types directly in their applications to speed up receive packet analysis.
> > >
> > > Moreover, this patch set translates i40e packet types to abstract packet types in i40e driver,
> > > and make the corresponding changes in test applications.
> > >
> > > Jijiang Liu (4):
> > >   Add packet type and IP header check in rte_mbuf
> > >   Remove the PKT_RX_TUNNEL_IPV4_HDR and the PKT_RX_TUNNEL_IPV6_HDR
> > >   Translate i40e packet types
> > >   Make the corresponding changes in test-pmd
> > >
> > >  app/test-pmd/csumonly.c         |   12 +-
> > >  app/test-pmd/rxonly.c           |   15 +-
> > >  lib/librte_mbuf/rte_mbuf.h      |  225 ++++++++++++++-
> > >  lib/librte_pmd_i40e/i40e_rxtx.c |  604 +++++++++++++++++++++------------------
> > >  4 files changed, 569 insertions(+), 287 deletions(-)
> > >
> >
> > The patch looks good to me in general.
> > Though I think it is not complete: we need to make sure that all PMDs RX functions will set mbuf's packet_type
> > to the defined value.
> > As right now, only i40e implementation can distinguish packet_type properly, I think all other PMDs
> > for the freshly received packet should do:
> > mbuf->packet_type = RTE_PTYPE_UNDEF;
> >
> > Another thing: right now mbuf's packet_type is uint16_t.
> > While enum rte_eth_packet_type will be interpreted by the compiler as 'int' (32bits).
> > We can either change enum to a lot of defines (which I don't really like to do) or probably just
> > add a comment somewhere that enum rte_eth_packet_type  should never exceed UINT16_MAX value?
> >
> Add a RTE_PTYPE_MAX value = UINT16_MAX to the enum, perhaps?

Yep, add something like RTE_PTYPE_MAX  = UINT16_MAX and RTE_PTYPE_MIN == 0 seems like a good thing to me too.

> 
> /Bruce

Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Liu, Jijiang]

> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Tuesday, November 18, 2014 11:29 PM
> To: Richardson, Bruce
> Cc: Liu, Jijiang; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> 
> 
> 
> > -----Original Message-----
> > From: Richardson, Bruce
> > Sent: Tuesday, November 18, 2014 1:08 PM
> > To: Ananyev, Konstantin
> > Cc: Liu, Jijiang; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> >
> > On Tue, Nov 18, 2014 at 11:33:24AM +0000, Ananyev, Konstantin wrote:
> > > Hi Frank,
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> > > > Sent: Tuesday, November 18, 2014 7:37 AM
> > > > To: dev@dpdk.org
> > > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > > >
> > > > The i40e NIC can recognize many packet types, including ordinary
> > > > L2 packet format and tunneling packet format such as IP in IP, IP
> > in
> > > > GRE, MAC in GRE and MAC in UDP.
> > > >
> > > > This patch set provides abstract definitions of packet types,
> > > > which can help user to use these packet types directly in their applications
> to speed up receive packet analysis.
> > > >
> > > > Moreover, this patch set translates i40e packet types to abstract
> > > > packet types in i40e driver, and make the corresponding changes in test
> applications.
> > > >
> > > > Jijiang Liu (4):
> > > >   Add packet type and IP header check in rte_mbuf
> > > >   Remove the PKT_RX_TUNNEL_IPV4_HDR and the
> PKT_RX_TUNNEL_IPV6_HDR
> > > >   Translate i40e packet types
> > > >   Make the corresponding changes in test-pmd
> > > >
> > > >  app/test-pmd/csumonly.c         |   12 +-
> > > >  app/test-pmd/rxonly.c           |   15 +-
> > > >  lib/librte_mbuf/rte_mbuf.h      |  225 ++++++++++++++-
> > > >  lib/librte_pmd_i40e/i40e_rxtx.c |  604
> > > > +++++++++++++++++++++------------------
> > > >  4 files changed, 569 insertions(+), 287 deletions(-)
> > > >
> > >
> > > The patch looks good to me in general.
> > > Though I think it is not complete: we need to make sure that all
> > > PMDs RX functions will set mbuf's packet_type to the defined value.
> > > As right now, only i40e implementation can distinguish packet_type
> > > properly, I think all other PMDs for the freshly received packet should do:
> > > mbuf->packet_type = RTE_PTYPE_UNDEF;

In current codes, the mbuf->packet_type  = 0 has already  been done in rte_pktmbuf_reset().

> > > Another thing: right now mbuf's packet_type is uint16_t.
> > > While enum rte_eth_packet_type will be interpreted by the compiler as 'int'
> (32bits).
> > > We can either change enum to a lot of defines (which I don't really
> > > like to do) or probably just add a comment somewhere that enum
> rte_eth_packet_type  should never exceed UINT16_MAX value?
> > >
> > Add a RTE_PTYPE_MAX value = UINT16_MAX to the enum, perhaps?
> 
> Yep, add something like RTE_PTYPE_MAX  = UINT16_MAX and RTE_PTYPE_MIN
> == 0 seems like a good thing to me too.

Ok,  will add RTE_PTYPE_MAX  = UINT16_MAX into rte_eth_packet_type.
Currently,  RTE_PTYPE_UNDEF is 0, if the RTE_PTYPE_MIN needed, and RTE_PTYPE_MIN = 1, but I think it is not necessary  to add RTE_PTYPE_MIN.

Moreover, there won't  be an icc compilation error for the following codes, so we can set mb-> packet_type  using enum paket_type  directly in i40e driver.
enum rte_eth_packet_type  paket_type;
mb-> packet_type  =  paket_type;    //packet_type is uint16 in mbuf.

But there will be an icc compilation error for the following codes, we must convert packet_type in mbuf .
enum rte_eth_packet_type paket_type;
paket_type = mb-> packet_type ;    //packet_type is uint16 in mbuf.

and it needs to change as follows to avoid compilation error using icc.
paket_type =(rte_eth_packet_type)  mb-> packet_type;

> 
> >
> > /Bruce

Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Ananyev, Konstantin]

> -----Original Message-----
> From: Liu, Jijiang
> Sent: Wednesday, November 19, 2014 3:53 AM
> To: Ananyev, Konstantin
> Cc: dev@dpdk.org; Richardson, Bruce
> Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> 
> 
> 
> > -----Original Message-----
> > From: Ananyev, Konstantin
> > Sent: Tuesday, November 18, 2014 11:29 PM
> > To: Richardson, Bruce
> > Cc: Liu, Jijiang; dev@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> >
> >
> >
> > > -----Original Message-----
> > > From: Richardson, Bruce
> > > Sent: Tuesday, November 18, 2014 1:08 PM
> > > To: Ananyev, Konstantin
> > > Cc: Liu, Jijiang; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > >
> > > On Tue, Nov 18, 2014 at 11:33:24AM +0000, Ananyev, Konstantin wrote:
> > > > Hi Frank,
> > > >
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> > > > > Sent: Tuesday, November 18, 2014 7:37 AM
> > > > > To: dev@dpdk.org
> > > > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > > > >
> > > > > The i40e NIC can recognize many packet types, including ordinary
> > > > > L2 packet format and tunneling packet format such as IP in IP, IP
> > > in
> > > > > GRE, MAC in GRE and MAC in UDP.
> > > > >
> > > > > This patch set provides abstract definitions of packet types,
> > > > > which can help user to use these packet types directly in their applications
> > to speed up receive packet analysis.
> > > > >
> > > > > Moreover, this patch set translates i40e packet types to abstract
> > > > > packet types in i40e driver, and make the corresponding changes in test
> > applications.
> > > > >
> > > > > Jijiang Liu (4):
> > > > >   Add packet type and IP header check in rte_mbuf
> > > > >   Remove the PKT_RX_TUNNEL_IPV4_HDR and the
> > PKT_RX_TUNNEL_IPV6_HDR
> > > > >   Translate i40e packet types
> > > > >   Make the corresponding changes in test-pmd
> > > > >
> > > > >  app/test-pmd/csumonly.c         |   12 +-
> > > > >  app/test-pmd/rxonly.c           |   15 +-
> > > > >  lib/librte_mbuf/rte_mbuf.h      |  225 ++++++++++++++-
> > > > >  lib/librte_pmd_i40e/i40e_rxtx.c |  604
> > > > > +++++++++++++++++++++------------------
> > > > >  4 files changed, 569 insertions(+), 287 deletions(-)
> > > > >
> > > >
> > > > The patch looks good to me in general.
> > > > Though I think it is not complete: we need to make sure that all
> > > > PMDs RX functions will set mbuf's packet_type to the defined value.
> > > > As right now, only i40e implementation can distinguish packet_type
> > > > properly, I think all other PMDs for the freshly received packet should do:
> > > > mbuf->packet_type = RTE_PTYPE_UNDEF;
> 
> In current codes, the mbuf->packet_type  = 0 has already  been done in rte_pktmbuf_reset().

Ok yes, I missed that: indeed we already do mbuf->packet_type  = 0 in rte_pktmbuf_reset().
Though, as I said in another mail our PMDs RX routines don't use rte_pktmbuf_reset() for performance reasons.
So, I still think that scalar ixgbe, igb/em and virtio/vmnext3 need to be updated. 

> 
> > > > Another thing: right now mbuf's packet_type is uint16_t.
> > > > While enum rte_eth_packet_type will be interpreted by the compiler as 'int'
> > (32bits).
> > > > We can either change enum to a lot of defines (which I don't really
> > > > like to do) or probably just add a comment somewhere that enum
> > rte_eth_packet_type  should never exceed UINT16_MAX value?
> > > >
> > > Add a RTE_PTYPE_MAX value = UINT16_MAX to the enum, perhaps?
> >
> > Yep, add something like RTE_PTYPE_MAX  = UINT16_MAX and RTE_PTYPE_MIN
> > == 0 seems like a good thing to me too.
> 
> Ok,  will add RTE_PTYPE_MAX  = UINT16_MAX into rte_eth_packet_type.
> Currently,  RTE_PTYPE_UNDEF is 0, if the RTE_PTYPE_MIN needed, and RTE_PTYPE_MIN = 1, but I think it is not necessary  to add
> RTE_PTYPE_MIN.

Why you need to setup RTE_PTYPE_MIN == 1?
Why it can't be done like that:

enum rte_eth_ptype { 
   RTE_PTYPE_MIN = 0,
   RTE_PTYPE_UDEF = RTE_PTYPE_MIN,
   ....
   RTE_PTYPE_MAX = UINT16_MAX
};
?

> 
> Moreover, there won't  be an icc compilation error for the following codes, so we can set mb-> packet_type  using enum paket_type
> directly in i40e driver.
> enum rte_eth_packet_type  paket_type;
> mb-> packet_type  =  paket_type;    //packet_type is uint16 in mbuf.
> 
> But there will be an icc compilation error for the following codes, we must convert packet_type in mbuf .
> enum rte_eth_packet_type paket_type;
> paket_type = mb-> packet_type ;    //packet_type is uint16 in mbuf.
> 
> and it needs to change as follows to avoid compilation error using icc.
> paket_type =(rte_eth_packet_type)  mb-> packet_type;

Not sure I understand you here.
I think you'll still need to do a direct conversion to keep old versions of icc happy:

mb-> packet_type  =  (uint16_t)paket_type;
...
paket_type =(rte_eth_packet_type) mb-> packet_type;    

> 
> >
> > >
> > > /Bruce

Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Zhang, Helin]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Tuesday, November 18, 2014 7:33 PM
> To: Liu, Jijiang; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> 
> Hi Frank,
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> > Sent: Tuesday, November 18, 2014 7:37 AM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> >
> > The i40e NIC can recognize many packet types, including ordinary L2
> > packet format and tunneling packet format such as IP in IP, IP in GRE, MAC in
> GRE and MAC in UDP.
> >
> > This patch set provides abstract definitions of packet types, which
> > can help user to use these packet types directly in their applications to speed
> up receive packet analysis.
> >
> > Moreover, this patch set translates i40e packet types to abstract
> > packet types in i40e driver, and make the corresponding changes in test
> applications.
> >
> > Jijiang Liu (4):
> >   Add packet type and IP header check in rte_mbuf
> >   Remove the PKT_RX_TUNNEL_IPV4_HDR and the
> PKT_RX_TUNNEL_IPV6_HDR
> >   Translate i40e packet types
> >   Make the corresponding changes in test-pmd
> >
> >  app/test-pmd/csumonly.c         |   12 +-
> >  app/test-pmd/rxonly.c           |   15 +-
> >  lib/librte_mbuf/rte_mbuf.h      |  225 ++++++++++++++-
> >  lib/librte_pmd_i40e/i40e_rxtx.c |  604
> > +++++++++++++++++++++------------------
> >  4 files changed, 569 insertions(+), 287 deletions(-)
> >
> 
> The patch looks good to me in general.
> Though I think it is not complete: we need to make sure that all PMDs RX
> functions will set mbuf's packet_type to the defined value.
We met quite a lot of similar situations, we designed a new way for i40e, then
have to rework igb/ixgbe. E.g. configuring reta, flow director, etc.
If possible, send the patch set as smaller as possible might be better. I guess
igb/ixgbe will be done soon later.

> As right now, only i40e implementation can distinguish packet_type properly, I
> think all other PMDs for the freshly received packet should do:
> mbuf->packet_type = RTE_PTYPE_UNDEF;
If I am not wrong, RTE_PTYPE_UNDEF can be 0, is packet_type in mbuf initialized to 0?
If yes, nothing needs to be done in igb/ixgbe for now.

> 
> Another thing: right now mbuf's packet_type is uint16_t.
> While enum rte_eth_packet_type will be interpreted by the compiler as 'int'
> (32bits).
> We can either change enum to a lot of defines (which I don't really like to do) or
> probably just add a comment somewhere that enum rte_eth_packet_type
> should never exceed UINT16_MAX value?
> 
> Konstantin
> 
> > --
> > 1.7.7.6

Regards,
Helin

Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Ananyev, Konstantin]

> -----Original Message-----
> From: Zhang, Helin
> Sent: Tuesday, November 18, 2014 2:12 PM
> To: Ananyev, Konstantin; Liu, Jijiang; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> 
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
> > Sent: Tuesday, November 18, 2014 7:33 PM
> > To: Liu, Jijiang; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> >
> > Hi Frank,
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> > > Sent: Tuesday, November 18, 2014 7:37 AM
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > >
> > > The i40e NIC can recognize many packet types, including ordinary L2
> > > packet format and tunneling packet format such as IP in IP, IP in GRE, MAC in
> > GRE and MAC in UDP.
> > >
> > > This patch set provides abstract definitions of packet types, which
> > > can help user to use these packet types directly in their applications to speed
> > up receive packet analysis.
> > >
> > > Moreover, this patch set translates i40e packet types to abstract
> > > packet types in i40e driver, and make the corresponding changes in test
> > applications.
> > >
> > > Jijiang Liu (4):
> > >   Add packet type and IP header check in rte_mbuf
> > >   Remove the PKT_RX_TUNNEL_IPV4_HDR and the
> > PKT_RX_TUNNEL_IPV6_HDR
> > >   Translate i40e packet types
> > >   Make the corresponding changes in test-pmd
> > >
> > >  app/test-pmd/csumonly.c         |   12 +-
> > >  app/test-pmd/rxonly.c           |   15 +-
> > >  lib/librte_mbuf/rte_mbuf.h      |  225 ++++++++++++++-
> > >  lib/librte_pmd_i40e/i40e_rxtx.c |  604
> > > +++++++++++++++++++++------------------
> > >  4 files changed, 569 insertions(+), 287 deletions(-)
> > >
> >
> > The patch looks good to me in general.
> > Though I think it is not complete: we need to make sure that all PMDs RX
> > functions will set mbuf's packet_type to the defined value.
> We met quite a lot of similar situations, we designed a new way for i40e, then
> have to rework igb/ixgbe. E.g. configuring reta, flow director, etc.
> If possible, send the patch set as smaller as possible might be better. I guess
> igb/ixgbe will be done soon later.
> 
> > As right now, only i40e implementation can distinguish packet_type properly, I
> > think all other PMDs for the freshly received packet should do:
> > mbuf->packet_type = RTE_PTYPE_UNDEF;
> If I am not wrong, RTE_PTYPE_UNDEF can be 0, is packet_type in mbuf initialized to 0?

Yes RTE_PTYPE_UNDEF == 0

> If yes, nothing needs to be done in igb/ixgbe for now.

Could  you explain to me why is that?
As I remember none of our RX functions reset the whole mbuf to all zeroes.
None of them even call rte_pktmbuf_reset() for performance reasons.
So what/who would prevent reset packet_type of the freshly received packet_type to zero?
BTW, I think that rte_pktmbuf_reset() need to reset packet_type too.

> 
> >
> > Another thing: right now mbuf's packet_type is uint16_t.
> > While enum rte_eth_packet_type will be interpreted by the compiler as 'int'
> > (32bits).
> > We can either change enum to a lot of defines (which I don't really like to do) or
> > probably just add a comment somewhere that enum rte_eth_packet_type
> > should never exceed UINT16_MAX value?
> >
> > Konstantin
> >
> > > --
> > > 1.7.7.6
> 
> Regards,
> Helin

Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Ananyev, Konstantin]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Tuesday, November 18, 2014 3:26 PM
> To: Zhang, Helin; Liu, Jijiang; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> 
> 
> 
> > -----Original Message-----
> > From: Zhang, Helin
> > Sent: Tuesday, November 18, 2014 2:12 PM
> > To: Ananyev, Konstantin; Liu, Jijiang; dev@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> >
> >
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
> > > Sent: Tuesday, November 18, 2014 7:33 PM
> > > To: Liu, Jijiang; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > >
> > > Hi Frank,
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> > > > Sent: Tuesday, November 18, 2014 7:37 AM
> > > > To: dev@dpdk.org
> > > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > > >
> > > > The i40e NIC can recognize many packet types, including ordinary L2
> > > > packet format and tunneling packet format such as IP in IP, IP in GRE, MAC in
> > > GRE and MAC in UDP.
> > > >
> > > > This patch set provides abstract definitions of packet types, which
> > > > can help user to use these packet types directly in their applications to speed
> > > up receive packet analysis.
> > > >
> > > > Moreover, this patch set translates i40e packet types to abstract
> > > > packet types in i40e driver, and make the corresponding changes in test
> > > applications.
> > > >
> > > > Jijiang Liu (4):
> > > >   Add packet type and IP header check in rte_mbuf
> > > >   Remove the PKT_RX_TUNNEL_IPV4_HDR and the
> > > PKT_RX_TUNNEL_IPV6_HDR
> > > >   Translate i40e packet types
> > > >   Make the corresponding changes in test-pmd
> > > >
> > > >  app/test-pmd/csumonly.c         |   12 +-
> > > >  app/test-pmd/rxonly.c           |   15 +-
> > > >  lib/librte_mbuf/rte_mbuf.h      |  225 ++++++++++++++-
> > > >  lib/librte_pmd_i40e/i40e_rxtx.c |  604
> > > > +++++++++++++++++++++------------------
> > > >  4 files changed, 569 insertions(+), 287 deletions(-)
> > > >
> > >
> > > The patch looks good to me in general.
> > > Though I think it is not complete: we need to make sure that all PMDs RX
> > > functions will set mbuf's packet_type to the defined value.
> > We met quite a lot of similar situations, we designed a new way for i40e, then
> > have to rework igb/ixgbe. E.g. configuring reta, flow director, etc.
> > If possible, send the patch set as smaller as possible might be better. I guess
> > igb/ixgbe will be done soon later.
> >
> > > As right now, only i40e implementation can distinguish packet_type properly, I
> > > think all other PMDs for the freshly received packet should do:
> > > mbuf->packet_type = RTE_PTYPE_UNDEF;
> > If I am not wrong, RTE_PTYPE_UNDEF can be 0, is packet_type in mbuf initialized to 0?
> 
> Yes RTE_PTYPE_UNDEF == 0
> 
> > If yes, nothing needs to be done in igb/ixgbe for now.
> 
> Could  you explain to me why is that?
> As I remember none of our RX functions reset the whole mbuf to all zeroes.
> None of them even call rte_pktmbuf_reset() for performance reasons.
> So what/who would prevent reset packet_type of the freshly received packet_type to zero?
> BTW, I think that rte_pktmbuf_reset() need to reset packet_type too.

You probably meant for ixgbe vector RX function?
Yes, that one already resets packet_type to 0. 
But scalar ixgbe and igb/em seems like not.
Same story I suppose with virtio and vmxnet3.

Konstantin

> 
> >
> > >
> > > Another thing: right now mbuf's packet_type is uint16_t.
> > > While enum rte_eth_packet_type will be interpreted by the compiler as 'int'
> > > (32bits).
> > > We can either change enum to a lot of defines (which I don't really like to do) or
> > > probably just add a comment somewhere that enum rte_eth_packet_type
> > > should never exceed UINT16_MAX value?
> > >
> > > Konstantin
> > >
> > > > --
> > > > 1.7.7.6
> >
> > Regards,
> > Helin

Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Zhang, Helin]

> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Tuesday, November 18, 2014 11:26 PM
> To: Zhang, Helin; Liu, Jijiang; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> 
> 
> 
> > -----Original Message-----
> > From: Zhang, Helin
> > Sent: Tuesday, November 18, 2014 2:12 PM
> > To: Ananyev, Konstantin; Liu, Jijiang; dev@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> >
> >
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev,
> > > Konstantin
> > > Sent: Tuesday, November 18, 2014 7:33 PM
> > > To: Liu, Jijiang; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > >
> > > Hi Frank,
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> > > > Sent: Tuesday, November 18, 2014 7:37 AM
> > > > To: dev@dpdk.org
> > > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > > >
> > > > The i40e NIC can recognize many packet types, including ordinary
> > > > L2 packet format and tunneling packet format such as IP in IP, IP
> > > > in GRE, MAC in
> > > GRE and MAC in UDP.
> > > >
> > > > This patch set provides abstract definitions of packet types,
> > > > which can help user to use these packet types directly in their
> > > > applications to speed
> > > up receive packet analysis.
> > > >
> > > > Moreover, this patch set translates i40e packet types to abstract
> > > > packet types in i40e driver, and make the corresponding changes in
> > > > test
> > > applications.
> > > >
> > > > Jijiang Liu (4):
> > > >   Add packet type and IP header check in rte_mbuf
> > > >   Remove the PKT_RX_TUNNEL_IPV4_HDR and the
> > > PKT_RX_TUNNEL_IPV6_HDR
> > > >   Translate i40e packet types
> > > >   Make the corresponding changes in test-pmd
> > > >
> > > >  app/test-pmd/csumonly.c         |   12 +-
> > > >  app/test-pmd/rxonly.c           |   15 +-
> > > >  lib/librte_mbuf/rte_mbuf.h      |  225 ++++++++++++++-
> > > >  lib/librte_pmd_i40e/i40e_rxtx.c |  604
> > > > +++++++++++++++++++++------------------
> > > >  4 files changed, 569 insertions(+), 287 deletions(-)
> > > >
> > >
> > > The patch looks good to me in general.
> > > Though I think it is not complete: we need to make sure that all
> > > PMDs RX functions will set mbuf's packet_type to the defined value.
> > We met quite a lot of similar situations, we designed a new way for
> > i40e, then have to rework igb/ixgbe. E.g. configuring reta, flow director, etc.
> > If possible, send the patch set as smaller as possible might be
> > better. I guess igb/ixgbe will be done soon later.
> >
> > > As right now, only i40e implementation can distinguish packet_type
> > > properly, I think all other PMDs for the freshly received packet should do:
> > > mbuf->packet_type = RTE_PTYPE_UNDEF;
> > If I am not wrong, RTE_PTYPE_UNDEF can be 0, is packet_type in mbuf
> initialized to 0?
> 
> Yes RTE_PTYPE_UNDEF == 0
> 
> > If yes, nothing needs to be done in igb/ixgbe for now.
> 
> Could  you explain to me why is that?
> As I remember none of our RX functions reset the whole mbuf to all zeroes.
> None of them even call rte_pktmbuf_reset() for performance reasons.
> So what/who would prevent reset packet_type of the freshly received
> packet_type to zero?
So mbuf header fields are not zero-ed by default? That might not be what I guessed.

> BTW, I think that rte_pktmbuf_reset() need to reset packet_type too.
> 
> >
> > >
> > > Another thing: right now mbuf's packet_type is uint16_t.
> > > While enum rte_eth_packet_type will be interpreted by the compiler as 'int'
> > > (32bits).
> > > We can either change enum to a lot of defines (which I don't really
> > > like to do) or probably just add a comment somewhere that enum
> > > rte_eth_packet_type should never exceed UINT16_MAX value?
> > >
> > > Konstantin
> > >
> > > > --
> > > > 1.7.7.6
> >
> > Regards,
> > Helin