diff mbox

[dpdk-dev,v3,03/16] mbuf: add definitions of unified packet types

Message ID 1424156374-21768-4-git-send-email-helin.zhang@intel.com (mailing list archive)
State Superseded, archived
Headers

Commit Message

Zhang, Helin Feb. 17, 2015, 6:59 a.m. UTC 
  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 <helin.zhang@intel.com>
---
 lib/librte_mbuf/rte_mbuf.h | 90 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

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

Comments

Olivier Matz Feb. 17, 2015, 9:01 a.m. UTC | #1 
Hi Helin,

On 02/17/2015 07:59 AM, 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 <helin.zhang@intel.com>

A formal definition of each flag is still missing. I explained
several times why it's needed. We must be able to answer to these
questions:

- If I'm developing a PMD, what fields should I check in the packet
   to set a specific flag?
- If I'm developing an application, if a specific flag is set, what
   checks can I skip?

Example with RTE_PTYPE_L3_IPV4:

- IP version field is 4
- no IP options (header size is 20)
- layer 2 identified the packet as IP (ex: ethertype=0x800)

I think we need such a definition for all packet types.

Regards,
Olivier
Zhang, Helin Feb. 20, 2015, 2:26 p.m. UTC | #2 
> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Tuesday, February 17, 2015 5:02 PM
> To: Zhang, Helin; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 03/16] mbuf: add definitions of unified packet
> types
> 
> Hi Helin,
> 
> On 02/17/2015 07:59 AM, 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 <helin.zhang@intel.com>
> 
> A formal definition of each flag is still missing. I explained several times why it's
> needed. We must be able to answer to these
> questions:
> 
> - If I'm developing a PMD, what fields should I check in the packet
>    to set a specific flag?
> - If I'm developing an application, if a specific flag is set, what
>    checks can I skip?
> 
> Example with RTE_PTYPE_L3_IPV4:
> 
> - IP version field is 4
> - no IP options (header size is 20)
> - layer 2 identified the packet as IP (ex: ethertype=0x800)
> 
> I think we need such a definition for all packet types.
You meant we need a detailed description of each packet type, right?
If yes, I can add those information soon. Thanks for the helps!

Regards,
Helin

> 
> Regards,
> Olivier
Olivier Matz Feb. 24, 2015, 9:09 a.m. UTC | #3 
Hi Helin,

On 02/20/2015 03:26 PM, Zhang, Helin wrote:
>> On 02/17/2015 07:59 AM, 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 <helin.zhang@intel.com>
>>
>> A formal definition of each flag is still missing. I explained several times why it's
>> needed. We must be able to answer to these
>> questions:
>>
>> - If I'm developing a PMD, what fields should I check in the packet
>>     to set a specific flag?
>> - If I'm developing an application, if a specific flag is set, what
>>     checks can I skip?
>>
>> Example with RTE_PTYPE_L3_IPV4:
>>
>> - IP version field is 4
>> - no IP options (header size is 20)
>> - layer 2 identified the packet as IP (ex: ethertype=0x800)
>>
>> I think we need such a definition for all packet types.
> You meant we need a detailed description of each packet type, right?
> If yes, I can add those information soon. Thanks for the helps!

Yes, I think this would be really helpful.

Thank you!
Olivier
Zhang, Helin Feb. 24, 2015, 1:38 p.m. UTC | #4 
> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Tuesday, February 24, 2015 5:09 PM
> To: Zhang, Helin; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 03/16] mbuf: add definitions of unified packet
> types
> 
> Hi Helin,
> 
> On 02/20/2015 03:26 PM, Zhang, Helin wrote:
> >> On 02/17/2015 07:59 AM, 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 <helin.zhang@intel.com>
> >>
> >> A formal definition of each flag is still missing. I explained
> >> several times why it's needed. We must be able to answer to these
> >> questions:
> >>
> >> - If I'm developing a PMD, what fields should I check in the packet
> >>     to set a specific flag?
> >> - If I'm developing an application, if a specific flag is set, what
> >>     checks can I skip?
> >>
> >> Example with RTE_PTYPE_L3_IPV4:
> >>
> >> - IP version field is 4
> >> - no IP options (header size is 20)
> >> - layer 2 identified the packet as IP (ex: ethertype=0x800)
> >>
> >> I think we need such a definition for all packet types.
> > You meant we need a detailed description of each packet type, right?
> > If yes, I can add those information soon. Thanks for the helps!
> 
> Yes, I think this would be really helpful.
OK. Got it. I will add them and send out v4 version. Thanks for your good suggestions!

Regards,
Helin

> 
> Thank you!
> Olivier
diff mbox

Patch

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 6f8e1dd..2cdf8a0 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -192,6 +192,96 @@  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                   0x00000000
+/* bit 3:0 for L2 types */
+#define RTE_PTYPE_L2_MAC                    0x00000001
+#define RTE_PTYPE_L2_MAC_TIMESYNC           0x00000002
+#define RTE_PTYPE_L2_ARP                    0x00000003
+#define RTE_PTYPE_L2_LLDP                   0x00000004
+#define RTE_PTYPE_L2_MASK                   0x0000000f
+/* bit 7:4 for L3 types */
+#define RTE_PTYPE_L3_IPV4                   0x00000010
+#define RTE_PTYPE_L3_IPV4_EXT               0x00000030
+#define RTE_PTYPE_L3_IPV6                   0x00000040
+#define RTE_PTYPE_L3_IPV4_EXT_UNKNOWN       0x00000090
+#define RTE_PTYPE_L3_IPV6_EXT               0x000000c0
+#define RTE_PTYPE_L3_IPV6_EXT_UNKNOWN       0x000000e0
+#define RTE_PTYPE_L3_MASK                   0x000000f0
+/* bit 11:8 for L4 types */
+#define RTE_PTYPE_L4_TCP                    0x00000100
+#define RTE_PTYPE_L4_UDP                    0x00000200
+#define RTE_PTYPE_L4_FRAG                   0x00000300
+#define RTE_PTYPE_L4_SCTP                   0x00000400
+#define RTE_PTYPE_L4_ICMP                   0x00000500
+#define RTE_PTYPE_L4_NONFRAG                0x00000600
+#define RTE_PTYPE_L4_MASK                   0x00000f00
+/* bit 15:12 for tunnel types */
+#define RTE_PTYPE_TUNNEL_IP                 0x00001000
+#define RTE_PTYPE_TUNNEL_GRE                0x00002000
+#define RTE_PTYPE_TUNNEL_VXLAN              0x00003000
+#define RTE_PTYPE_TUNNEL_NVGRE              0x00004000
+#define RTE_PTYPE_TUNNEL_GENEVE             0x00005000
+#define RTE_PTYPE_TUNNEL_GRENAT             0x00006000
+#define RTE_PTYPE_TUNNEL_MASK               0x0000f000
+/* bit 19:16 for inner L2 types */
+#define RTE_PTYPE_INNER_L2_MAC              0x00010000
+#define RTE_PTYPE_INNER_L2_MAC_VLAN         0x00020000
+#define RTE_PTYPE_INNER_L2_MASK             0x000f0000
+/* bit 23:20 for inner L3 types */
+#define RTE_PTYPE_INNER_L3_IPV4             0x00100000
+#define RTE_PTYPE_INNER_L3_IPV4_EXT         0x00200000
+#define RTE_PTYPE_INNER_L3_IPV6             0x00300000
+#define RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN 0x00400000
+#define RTE_PTYPE_INNER_L3_IPV6_EXT         0x00500000
+#define RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN 0x00600000
+#define RTE_PTYPE_INNER_INNER_L3_MASK       0x00f00000
+/* bit 27:24 for inner L4 types */
+#define RTE_PTYPE_INNER_L4_TCP              0x01000000
+#define RTE_PTYPE_INNER_L4_UDP              0x02000000
+#define RTE_PTYPE_INNER_L4_FRAG             0x03000000
+#define RTE_PTYPE_INNER_L4_SCTP             0x04000000
+#define RTE_PTYPE_INNER_L4_ICMP             0x05000000
+#define RTE_PTYPE_INNER_L4_NONFRAG          0x06000000
+#define RTE_PTYPE_INNER_L4_MASK             0x0f000000
+/* bit 31:28 reserved */
+
+/**
+ * Check if the (outer) L3 header is IPv4. To avoid comparing IPv4 types one by
+ * one, bit 4 is selected to be used for IPv4 only. Then checking bit 4 can
+ * determin if it is an IPV4 packet.
+ */
+#define  RTE_ETH_IS_IPV4_HDR(ptype) ((ptype) & RTE_PTYPE_L3_IPV4)
+
+/**
+ * Check if the (outer) L3 header is IPv4. To avoid comparing IPv4 types one by
+ * one, bit 6 is selected to be used for IPv4 only. Then checking bit 6 can
+ * determin if it is an IPV4 packet.
+ */
+#define  RTE_ETH_IS_IPV6_HDR(ptype) ((ptype) & RTE_PTYPE_L3_IPV6)
+
+/* Check if it is a tunneling packet */
+#define RTE_ETH_IS_TUNNEL_PKT(ptype) ((ptype) & RTE_PTYPE_TUNNEL_MASK)
+
 /**
  * Get the name of a RX offload flag
  *