On Thu, Jan 05, 2017 at 03:12:01AM +0000, Zhao1, Wei wrote:

Hi, adrien

quoted

-----Original Message-----
From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
Sent: Tuesday, January 3, 2017 10:08 PM
To: Zhao1, Wei <redacted>
Cc: dev@dpdk.org; Lu, Wenzhuo <redacted>
Subject: Re: [dpdk-dev] [PATCH v2 14/18] net/ixgbe: parse L2 tunnel filter

Hi Wei,

On Fri, Dec 30, 2016 at 03:53:06PM +0800, Wei Zhao wrote:

quoted

check if the rule is a L2 tunnel rule, and get the L2 tunnel info.

Signed-off-by: Wei Zhao <redacted>
Signed-off-by: Wenzhuo Lu <redacted>

---

v2:
--add new error set function
--change return value type of parser function
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 269

+++++++++++++++++++++++++++++++++++----

quoted

 lib/librte_ether/rte_flow.h      |  32 +++++
 2 files changed, 273 insertions(+), 28 deletions(-)

[...]

quoted

diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 98084ac..e9e6220 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h

@@ -268,6 +268,13 @@ enum rte_flow_item_type {
 	 * See struct rte_flow_item_vxlan.
 	 */
 	RTE_FLOW_ITEM_TYPE_VXLAN,
+
+	/**
+	  * Matches a E_TAG header.
+	  *
+	  * See struct rte_flow_item_e_tag.
+	  */
+	RTE_FLOW_ITEM_TYPE_E_TAG,
 };

 /**

@@ -454,6 +461,31 @@ struct rte_flow_item_vxlan {  };

 /**
+ * RTE_FLOW_ITEM_TYPE_E_TAG.
+ *
+ * Matches a E-tag header.
+ */
+struct rte_flow_item_e_tag {
+	struct ether_addr dst; /**< Destination MAC. */
+	struct ether_addr src; /**< Source MAC. */
+	uint16_t e_tag_ethertype; /**< E-tag EtherType, 0x893F. */
+	uint16_t e_pcp:3; /**<  E-PCP */
+	uint16_t dei:1; /**< DEI */
+	uint16_t in_e_cid_base:12; /**< Ingress E-CID base */
+	uint16_t rsv:2; /**< reserved */
+	uint16_t grp:2; /**< GRP */
+	uint16_t e_cid_base:12; /**< E-CID base */
+	uint16_t in_e_cid_ext:8; /**< Ingress E-CID extend */
+	uint16_t e_cid_ext:8; /**< E-CID extend */
+	uint16_t type; /**< MAC type. */
+	unsigned int tags; /**< Number of 802.1Q/ad tags defined. */
+	struct {
+		uint16_t tpid; /**< Tag protocol identifier. */
+		uint16_t tci; /**< Tag control information. */
+	} tag[]; /**< 802.1Q/ad tag definitions, outermost first. */ };

[...]

See my previous reply [1], this definition is not endian-safe and comprises
protocols defined as independent items (namely ETH and VLAN). Here is an
untested suggestion:

 struct rte_flow_item_e_tag {
     uint16_t tpid; /**< Tag protocol identifier (0x893F). */
     /** E-Tag control information (E-TCI). */
     uint16_t epcp_edei_in_ecid_b; /**< E-PCP (3b), E-DEI (1b), ingress E-CID
base (12b). */
     uint16_t rsvd_grp_ecid_b; /**< Reserved (2b), GRP (2b), E-CID base (12b).
*/
     uint8_t in_ecid_e; /**< Ingress E-CID ext. */
     uint8_t ecid_e; /**< E-CID ext. */
 };

Applications are responsibile for breaking down and filling individual fields
properly. Ethernet header would be provided as its own item as shown in
this testpmd flow command example:

 flow create 0 ingress pattern eth / e_tag in_ecid_base is 42 / end actions
drop / end

In this case , is  eth  an option or mandatory? 
I think it is optional, because user may do not have any parameter in ETH  config.

Normally, protocol items start from L2 so applications *should* provide
ETH otherwise it is an error.

Now a PMD may also allow it to be implicit when it is unambiguous (e.g. an
imaginary ETH item provided without a mask) as described in the "UDPv6
anywhere" example [2]. It's up to you.

quoted

Note, all multibyte values are in network order like other protocol header
definitions.

[1] http://dpdk.org/ml/archives/dev/2016-December/053181.html
    Message ID: 20161223081310.GH10340@6wind.com

[2] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#matching-pattern

-- 
Adrien Mazarguil
6WIND