From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: [PATCH v2 14/18] net/ixgbe: parse L2 tunnel filter Date: Tue, 3 Jan 2017 15:07:59 +0100 Message-ID: <20170103140759.GA12822@6wind.com> References: <1483084390-53159-1-git-send-email-wei.zhao1@intel.com> <1483084390-53159-15-git-send-email-wei.zhao1@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org, Wenzhuo Lu To: Wei Zhao Return-path: Received: from mail-wj0-f171.google.com (mail-wj0-f171.google.com [209.85.210.171]) by dpdk.org (Postfix) with ESMTP id 649352B9C for ; Tue, 3 Jan 2017 15:08:10 +0100 (CET) Received: by mail-wj0-f171.google.com with SMTP id tq7so208737428wjb.0 for ; Tue, 03 Jan 2017 06:08:10 -0800 (PST) Content-Disposition: inline In-Reply-To: <1483084390-53159-15-git-send-email-wei.zhao1@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Wei, On Fri, Dec 30, 2016 at 03:53:06PM +0800, Wei Zhao wrote: > check if the rule is a L2 tunnel rule, and get the L2 tunnel info. > > Signed-off-by: Wei Zhao > Signed-off-by: Wenzhuo Lu > > --- > > v2: > --add new error set function > --change return value type of parser function > --- > drivers/net/ixgbe/ixgbe_ethdev.c | 269 +++++++++++++++++++++++++++++++++++---- > lib/librte_ether/rte_flow.h | 32 +++++ > 2 files changed, 273 insertions(+), 28 deletions(-) [...] > 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 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 -- Adrien Mazarguil 6WIND