Re: [dpdk-dev] [PATCH 01/17] mbuf: add definitions of unified packet types

[Olivier MATZ <olivier.matz@6wind.com>]

Hi Helin,

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 <helin.zhang@intel.com>
> Signed-off-by: Cunming Liang <cunming.liang@intel.com>
> Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
> ---
>  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.

Is there a reason why using this specific order?

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?

> + *
> + * To be compitable with Vector PMD, RTE_PTYPE_L3_IPV4, RTE_PTYPE_L3_IPV4_EXT,

compitable -> compatible

> + * 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                   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 */

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?

My understanding is:

- 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

I think it would solve the problem asked by Stephen
http://dpdk.org/ml/archives/dev/2015-January/011550.html

> +/* 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 */

Same question for L4.

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.

> +/* 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 */
> +#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
>   *
> 

Thanks,
Olivier