From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 06EF72A61 for ; Mon, 2 Feb 2015 02:44:12 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 01 Feb 2015 17:39:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,503,1418112000"; d="scan'208";a="521100216" Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98]) by orsmga003.jf.intel.com with ESMTP; 01 Feb 2015 17:36:41 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by PGSMSX106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 2 Feb 2015 09:43:26 +0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.91]) by shsmsx102.ccr.corp.intel.com ([169.254.2.124]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 09:43:25 +0800 From: "Zhang, Helin" To: Olivier MATZ , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 01/17] mbuf: add definitions of unified packet types Thread-Index: AQHQPJSYnLd4IgnLikW5X4rRpE4JWJzciU5w Date: Mon, 2 Feb 2015 01:43:25 +0000 Message-ID: References: <1421637666-16872-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-2-git-send-email-helin.zhang@intel.com> <54CB8D81.2050205@6wind.com> In-Reply-To: <54CB8D81.2050205@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 01/17] mbuf: add definitions of unified packet types X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 01:44:14 -0000 Hi Olivier > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Friday, January 30, 2015 9:56 PM > To: Zhang, Helin; dev@dpdk.org > Cc: Stephen Hemminger > Subject: Re: [dpdk-dev] [PATCH 01/17] mbuf: add definitions of unified pa= cket > types >=20 > Hi Helin, >=20 > On 01/29/2015 04:15 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 tunnel type, L3 type, > > L4 type and inner L3 type fields, and can be stored in 16 bits mbuf > > field of 'packet_type'. > > > > Signed-off-by: Helin Zhang > > Signed-off-by: Cunming Liang > > Signed-off-by: Jijiang Liu > > --- > > lib/librte_mbuf/rte_mbuf.h | 74 > > ++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 74 insertions(+) > > > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > > index 16059c6..94ae344 100644 > > --- a/lib/librte_mbuf/rte_mbuf.h > > +++ b/lib/librte_mbuf/rte_mbuf.h > > @@ -165,6 +165,80 @@ extern "C" { > > /* Use final bit of flags to indicate a control mbuf */ > > #define CTRL_MBUF_FLAG (1ULL << 63) /**< Mbuf contains control > data */ > > > > +/* > > + * Sixteen bits are divided into several fields to mark packet types. > > +Note that > > + * each field is indexical. > > + * - Bit 3:0 is for tunnel types. > > + * - Bit 7:4 is for L3 or outer L3 (for tunneling case) types. > > + * - Bit 10:8 is for L4 types. It can also be used for inner L4 types = for > > + * tunneling packets. > > + * - Bit 13:11 is for inner L3 types. > > + * - Bit 15:14 is reserved. >=20 > Is there a reason why using this specific order? Yes, to support ixgbe Vector PMD, outer L3 types and L4 types need to be co= ntiguous and in this order. >=20 > Also, there are 4 bits for outer L3 types and 3 bits for inner L3 types, = but both of > them have 6 different supported types. Is it intentional? Yes, it is to support ixgbe Vector PMD. Contiguous 7 bits are needed, thoug= h 1 bit wasted. >=20 > > + * > > + * To be compitable with Vector PMD, RTE_PTYPE_L3_IPV4, > > + RTE_PTYPE_L3_IPV4_EXT, >=20 > compitable -> compatible Good catch! It will be fixed in next version. Thanks! >=20 > > + * 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 bit= s. > > + * > > + * 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 0x0000 /* > 0b0000000000000000 */ > > +/* bit 3:0 for tunnel types */ > > +#define RTE_PTYPE_TUNNEL_IP 0x0001 /* > 0b0000000000000001 */ > > +#define RTE_PTYPE_TUNNEL_TCP 0x0002 /* > 0b0000000000000010 */ > > +#define RTE_PTYPE_TUNNEL_UDP 0x0003 /* > 0b0000000000000011 */ > > +#define RTE_PTYPE_TUNNEL_GRE 0x0004 /* > 0b0000000000000100 */ > > +#define RTE_PTYPE_TUNNEL_VXLAN 0x0005 /* > 0b0000000000000101 */ > > +#define RTE_PTYPE_TUNNEL_NVGRE 0x0006 /* > 0b0000000000000110 */ > > +#define RTE_PTYPE_TUNNEL_GENEVE 0x0007 /* > 0b0000000000000111 */ > > +#define RTE_PTYPE_TUNNEL_GRENAT 0x0008 /* > 0b0000000000001000 */ > > +#define RTE_PTYPE_TUNNEL_GRENAT_MAC 0x0009 /* > 0b0000000000001001 */ > > +#define RTE_PTYPE_TUNNEL_GRENAT_MACVLAN 0x000a /* > 0b0000000000001010 */ > > +#define RTE_PTYPE_TUNNEL_MASK 0x000f /* > 0b0000000000001111 */ > > +/* bit 7:4 for L3 types */ > > +#define RTE_PTYPE_L3_IPV4 0x0010 /* > 0b0000000000010000 */ > > +#define RTE_PTYPE_L3_IPV4_EXT 0x0030 /* > 0b0000000000110000 */ > > +#define RTE_PTYPE_L3_IPV6 0x0040 /* > 0b0000000001000000 */ > > +#define RTE_PTYPE_L3_IPV4_EXT_UNKNOWN 0x0090 /* > 0b0000000010010000 */ > > +#define RTE_PTYPE_L3_IPV6_EXT 0x00c0 /* > 0b0000000011000000 */ > > +#define RTE_PTYPE_L3_IPV6_EXT_UNKNOWN 0x00e0 /* > 0b0000000011100000 */ > > +#define RTE_PTYPE_L3_MASK 0x00f0 /* > 0b0000000011110000 */ >=20 > can we expect that when RTE_PTYPE_L3_IPV4, RTE_PTYPE_L3_IPV4_EXT or > RTE_PTYPE_L3_IPV4_EXT_UNKNOWN is set, the hardware also verified the > L3 checksum? RTE_PTYPE_L3_IPV4 means there is NONE-EXT. Each time only one of above 3 ca= n be set. These bits don't indicate any checksum, checksum should be indicated by oth= er flags. They are just for packet types hardware can recognized. >=20 > My understanding is: >=20 > - if packet_type is IPv4* and PKT_RX_IP_CKSUM_BAD is 0 > -> checksum was checked by hw and is good > - if packet_type is IPv4* and PKT_RX_IP_CKSUM_BAD is 1 > -> checksum was checked by hw and is bad > - if packet_type is not IPv4* > -> checksum was not checked by hw >=20 > I think it would solve the problem asked by Stephen > http://dpdk.org/ml/archives/dev/2015-January/011550.html >=20 > > +/* bit 10:8 for L4 types */ > > +#define RTE_PTYPE_L4_TCP 0x0100 /* > 0b0000000100000000 */ > > +#define RTE_PTYPE_L4_UDP 0x0200 /* > 0b0000001000000000 */ > > +#define RTE_PTYPE_L4_FRAG 0x0300 /* > 0b0000001100000000 */ > > +#define RTE_PTYPE_L4_SCTP 0x0400 /* > 0b0000010000000000 */ > > +#define RTE_PTYPE_L4_ICMP 0x0500 /* > 0b0000010100000000 */ > > +#define RTE_PTYPE_L4_NONFRAG 0x0600 /* > 0b0000011000000000 */ > > +#define RTE_PTYPE_L4_MASK 0x0700 /* > 0b0000011100000000 */ >=20 > Same question for L4. >=20 > Note: it would means that if a hardware is able to recognize a TCP packet= but > not to verify the checksum, it has to set RTE_PTYPE_L4 to unknown. >=20 > > +/* bit 13:11 for inner L3 types */ > > +#define RTE_PTYPE_INNER_L3_IPV4 0x0800 /* > 0b0000100000000000 */ > > +#define RTE_PTYPE_INNER_L3_IPV4_EXT 0x1000 /* > 0b0001000000000000 */ > > +#define RTE_PTYPE_INNER_L3_IPV6 0x1800 /* > 0b0001100000000000 */ > > +#define RTE_PTYPE_INNER_L3_IPV6_EXT 0x2000 /* > 0b0010000000000000 */ > > +#define RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN 0x2800 /* > > +0b0010100000000000 */ #define > RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN 0x3000 /* 0b0011000000000000 > */ We cannot define the hardware behaviors, it just reports the hardware recog= nized packet information directly to the mbuf. Based on my experiment on i40e hardware, if a IPV4 packet with wrong checks= um, by default, the PMD driver cannot see the packet at all. So we don't need t= o care about it too much! Thanks for the good comments! > > +#define RTE_PTYPE_INNER_L3_MASK 0x3800 /* > 0b0011100000000000 */ > > +/* bit 15:14 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 > > * > > >=20 > Thanks, > Olivier