DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Zhang, Helin" <helin.zhang@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC 01/17] mbuf: add definitions of unified packet types
Date: Mon, 19 Jan 2015 16:19:36 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB977258213DDE25@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <1421637803-17034-2-git-send-email-helin.zhang@intel.com>



> -----Original Message-----
> From: Zhang, Helin
> Sent: Monday, January 19, 2015 3:23 AM
> To: dev@dpdk.org
> Cc: Liang, Cunming; Liu, Jijiang; Ananyev, Konstantin; Zhang, Helin
> Subject: [RFC 01/17] mbuf: add definitions of unified packet types
> 
> 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 | 68 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
> 
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 16059c6..94eb38f 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -165,6 +165,74 @@ 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.
> + *
> + * To be compitable 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.
> + */
> +#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_IPV6_EXT               0x00c0 /* 0b0000000011000000 */
> +#define RTE_PTYPE_L3_IPV4_EXT_UNKNOWN       0x00d0 /* 0b0000000011010000 */
> +#define RTE_PTYPE_L3_IPV6_EXT_UNKNOWN       0x00e0 /* 0b0000000011100000 */
> +#define RTE_PTYPE_L3_MASK                   0x00f0 /* 0b0000000011110000 */

I still think it would be better to use enum not bit-set for IPv4/IPv6 distinction, but if you set it that way,
can you at least take advantage of it and make RTE_ETH_IS_IPV4_HDR() not require 3 comparisons?
I think it is doable if you set bit 4 for IPv4 types only (you already do that)
and bit 6 for IPv6 types only.
For that, I think, you can make RTE_PTYPE_L3_IPV4_EXT_UNKNOWN == 0xb0  /* 0b0000000010110000 */
Then you can:

#define  RTE_ETH_IS_IPV4_HDR(ptype)    (((ptype) & RTE_PTYPE_L3_IPV4) != 0)
#define  RTE_ETH_IS_IPV6_HDR(ptype)    (((ptype) & RTE_PTYPE_L3_IPV6) != 0)

I suppose that would be faster then what you propose below,
and would probably require less changes in our sample apps.

Konstantin

> +/* 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 */
> +/* 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 */
> +#define  RTE_ETH_IS_IPV4_HDR(ptype) \
> +	(((ptype) & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV4 || \
> +	((ptype) & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV4_EXT || \
> +	((ptype) & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV4_EXT_UNKNOWN)
> +
> +/* Check if the (outer) L3 header is IPv6 */
> +#define  RTE_ETH_IS_IPV6_HDR(ptype) \
> +	(((ptype) & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV6 || \
> +	((ptype) & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV6_EXT || \
> +	((ptype) & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV6_EXT_UNKNOWN)
> +
> +/* 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
>   *
> --
> 1.8.1.4

  reply	other threads:[~2015-01-19 16:19 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19  3:23 [dpdk-dev] [RFC 00/17] unified packet type Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 01/17] mbuf: add definitions of unified packet types Helin Zhang
2015-01-19 16:19   ` Ananyev, Konstantin [this message]
2015-01-20  3:47     ` Zhang, Helin
2015-01-19 16:33   ` Neil Horman
2015-01-19 17:27     ` Olivier MATZ
2015-01-19 18:15       ` Neil Horman
2015-01-20  2:28       ` Zhang, Helin
2015-01-20  9:53         ` Olivier MATZ
2015-01-19  3:23 ` [dpdk-dev] [RFC 02/17] e1000: support of unified packet type Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 03/17] ixgbe: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 04/17] " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 05/17] i40e: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 06/17] bond: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 07/17] enic: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 08/17] vmxnet3: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 09/17] app/test-pipeline: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 10/17] app/test-pmd: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 11/17] app/test: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 12/17] examples/ip_fragmentation: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 13/17] examples/ip_reassembly: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 14/17] examples/l3fwd-acl: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 15/17] examples/l3fwd-power: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 16/17] examples/l3fwd: " Helin Zhang
2015-01-19  3:23 ` [dpdk-dev] [RFC 17/17] mbuf: remove old packet type bit masks for ol_flags Helin Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2601191342CEEE43887BDE71AB977258213DDE25@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=dev@dpdk.org \
    --cc=helin.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).