[dpdk-dev] [PATCH v4 03/18] mbuf: add definitions of unified packet types

2015-02-27 Thread Helin Zhang
As there are only 6 bit flags in ol_flags for indicating packet
types, which is not enough to describe all the possible packet
types hardware can recognize. For example, i40e hardware can
recognize more than 150 packet types. Unified packet type is
composed of L2 type, L3 type, L4 type, tunnel type, inner L2 type,
inner L3 type and inner L4 type fields, and can be stored in
'struct rte_mbuf' of 32 bits field 'packet_type'.

Signed-off-by: Helin Zhang 
---
 lib/librte_mbuf/rte_mbuf.h | 253 +
 1 file changed, 253 insertions(+)

v3 changes:
* Put the definitions of unified packet type into a single patch.

v4 changes:
* Added detailed description of each packet types.

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index f5b7a8b..8de57fd 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -194,6 +194,259 @@ extern "C" {
 /* Use final bit of flags to indicate a control mbuf */
 #define CTRL_MBUF_FLAG   (1ULL << 63) /**< Mbuf contains control data */

+/*
+ * 32 bits are divided into several fields to mark packet types. Note that
+ * each field is indexical.
+ * - Bit 3:0 is for L2 types.
+ * - Bit 7:4 is for L3 or outer L3 (for tunneling case) types.
+ * - Bit 11:8 is for L4 or outer L4 (for tunneling case) types.
+ * - Bit 15:12 is for tunnel types.
+ * - Bit 19:16 is for inner L2 types.
+ * - Bit 23:20 is for inner L3 types.
+ * - Bit 27:24 is for inner L4 types.
+ * - Bit 31:28 is reserved.
+ *
+ * To be compatible with Vector PMD, RTE_PTYPE_L3_IPV4, RTE_PTYPE_L3_IPV4_EXT,
+ * RTE_PTYPE_L3_IPV6, RTE_PTYPE_L3_IPV6_EXT, RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP
+ * and RTE_PTYPE_L4_SCTP should be kept as below in a contiguous 7 bits.
+ *
+ * Note that L3 types values are selected for checking IPV4/IPV6 header from
+ * performance point of view. Reading annotations of RTE_ETH_IS_IPV4_HDR and
+ * RTE_ETH_IS_IPV6_HDR is needed for any future changes of L3 type values.
+ */
+#define RTE_PTYPE_UNKNOWN   0x
+/**
+ * MAC (Media Access Control) packet type.
+ * It is used for outer packet for tunneling cases.
+ */
+#define RTE_PTYPE_L2_MAC0x0001
+/**
+ * MAC (Media Access Control) packet type for time sync.
+ */
+#define RTE_PTYPE_L2_MAC_TIMESYNC   0x0002
+/**
+ * ARP (Address Resolution Protocol) packet type.
+ */
+#define RTE_PTYPE_L2_ARP0x0003
+/**
+ * LLDP (Link Layer Discovery Protocol) packet type.
+ */
+#define RTE_PTYPE_L2_LLDP   0x0004
+/**
+ * Mask of layer 2 packet types.
+ * It is used for outer packet for tunneling cases.
+ */
+#define RTE_PTYPE_L2_MASK   0x000f
+/**
+ * IP (Internet Protocol) version 4 packet type.
+ * It is used for outer packet for tunneling cases, and does not contain any
+ * header option.
+ */
+#define RTE_PTYPE_L3_IPV4   0x0010
+/**
+ * IP (Internet Protocol) version 4 packet type.
+ * It is used for outer packet for tunneling cases, and contains header
+ * options.
+ */
+#define RTE_PTYPE_L3_IPV4_EXT   0x0030
+/**
+ * IP (Internet Protocol) version 6 packet type.
+ * It is used for outer packet for tunneling cases, and does not contain any
+ * extension header.
+ */
+#define RTE_PTYPE_L3_IPV6   0x0040
+/**
+ * IP (Internet Protocol) version 4 packet type.
+ * It is used for outer packet for tunneling cases, and may or maynot contain
+ * header options.
+ */
+#define RTE_PTYPE_L3_IPV4_EXT_UNKNOWN   0x0090
+/**
+ * IP (Internet Protocol) version 6 packet type.
+ * It is used for outer packet for tunneling cases, and contains extension
+ * headers.
+ */
+#define RTE_PTYPE_L3_IPV6_EXT   0x00c0
+/**
+ * IP (Internet Protocol) version 6 packet type.
+ * It is used for outer packet for tunneling cases, and may or maynot contain
+ * extension headers.
+ */
+#define RTE_PTYPE_L3_IPV6_EXT_UNKNOWN   0x00e0
+/**
+ * Mask of layer 3 packet types.
+ * It is used for outer packet for tunneling cases.
+ */
+#define RTE_PTYPE_L3_MASK   0x00f0
+/**
+ * TCP (Transmission Control Protocol) packet type.
+ * It is used for outer packet for tunneling cases.
+ */
+#define RTE_PTYPE_L4_TCP0x0100
+/**
+ * UDP (User Datagram Protocol) packet type.
+ * It is used for outer packet for tunneling cases.
+ */
+#define RTE_PTYPE_L4_UDP0x0200
+/**
+ * Fragmented IP (Internet Protocol) packet type.
+ * It is used for outer packet for tunneling cases.
+ */
+#define RTE_PTYPE_L4_FRAG   0x0300
+/**
+ * SCTP (Stream Control Transmission Protocol) packet type.
+ * It is used for outer packet for tunneling cases.
+ */
+#define RTE_PTYPE_L4_SCTP   0x0400
+/**
+ * ICMP (Internet Control Message Protocol) packet type.
+ * It is used for outer packet for tunneling cases.
+ */
+#define RTE_PTYPE_L4_ICMP   

[dpdk-dev] [PATCH v4 03/18] mbuf: add definitions of unified packet types

2015-02-27 Thread Olivier MATZ
Hi Helin,

On 02/27/2015 02:11 PM, Helin Zhang wrote:
> As there are only 6 bit flags in ol_flags for indicating packet
> types, which is not enough to describe all the possible packet
> types hardware can recognize. For example, i40e hardware can
> recognize more than 150 packet types. Unified packet type is
> composed of L2 type, L3 type, L4 type, tunnel type, inner L2 type,
> inner L3 type and inner L4 type fields, and can be stored in
> 'struct rte_mbuf' of 32 bits field 'packet_type'.
> 
> Signed-off-by: Helin Zhang 

That's not what I asked in
http://dpdk.org/ml/archives/dev/2015-February/013423.html

A definition of what is the meaning of a packet type in terms of
packet content is really required for the PMD developer and for
the application developer.

By reading the comment, we should be able to answer to the following
question:
- What are the required conditions on the packet headers to recognize
  this type? The conditions should be formally described in the comment.

By reading the comment, we should be able to know whether the following
packets can or must not be recognized as an RTE_PTYPE_L3_IPV4:

>

>

>

>

>

>

>

>

...


Here is an example about why it is important:

Let's assume the definition of RTE_PTYPE_L3_IPV4 is:
- IP version field is 4
- no IP options (header size is 20, ihl=5)
- layer 2 identified the packet as IP (ex: ethertype=0x800)

If a hardware XYZ is able to recognize that a packet is an IP packet by
just checking the ethertype without checking the IP version field, the
PMD has to check by software that IHL is 5 and IP version is 4.

Regards,
Olivier