From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f181.google.com (mail-wj0-f181.google.com [209.85.210.181]) by dpdk.org (Postfix) with ESMTP id 03FCE2B91 for ; Thu, 5 Jan 2017 09:52:10 +0100 (CET) Received: by mail-wj0-f181.google.com with SMTP id tn15so29745726wjb.1 for ; Thu, 05 Jan 2017 00:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zjDXx7VEWhBBqyuumegCpjZYSenbtkQBTTojC+l+Adg=; b=c3E7Ow6HcXZW+Q5dxSZr3oOQfr163heAMlwwzmgIT/I0xRr2R2UgsmzTvWmMUEd34N ityHy7V+yY9XGXLcBqKgoDMCmI/NS8TgQKr2AAzEnjJEaGGrNeW7I687au3jlN8ezmKT bLu+i45sODicnDT76K3mgO2zib+MRB3QedfpIgX3sd/ai7JgLjFR4ca4+CViTQf5wGQI NwMA+dAyqGSpX2Ut2f8iEP/FoqctF5JnGyQOsR/LmnumWePSDuoePHZqzrJ819kcU7Un PimtzEPtUK9pRrwDhCqxhpy7ZYDcpaN87bF+6MERh0LMtp/PgHnX3C4CO2AOk/UdbCkg Zgug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zjDXx7VEWhBBqyuumegCpjZYSenbtkQBTTojC+l+Adg=; b=QdhR9uFdFPrhnlJAe8RSEIkeY3flIkLGpj+gtJ6bJs94TJd3qsRISK/8LaAlO/+tnj fuhAhBeAooy+jbcwkobarAHf1kJOiBq18YoA0cYWfE+tYHoFwXxTc+Vvj6g6C2aN+R2H H69azL/ajkZmtr1iS74Ev8xXvP35qT+us8QzWaiV3hyP1U6FRDC48Fdo3ytztZFC7mcD GOLyl4wDWqQZaDcijblpdGNT6Jx62lOKiFpOC8CWMJ6Y4pfNjJx1fkbf7JiE55v5YFZw vJcy352QIjzuRu8LGEWGGKDjzJxc/+8n7tfWXseSp3ZZpWnNVfM0vvscM7BXr5p7MheO QS5g== X-Gm-Message-State: AIkVDXL39NwZwZIQQMvzY+WZilburuWGY27YCqtofAjZAHufZPh7viKmGTNxqesCIORmcSQu X-Received: by 10.194.122.101 with SMTP id lr5mr59250353wjb.210.1483606330657; Thu, 05 Jan 2017 00:52:10 -0800 (PST) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id c133sm99737517wme.12.2017.01.05.00.52.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 00:52:09 -0800 (PST) Date: Thu, 5 Jan 2017 09:52:03 +0100 From: Adrien Mazarguil To: "Zhao1, Wei" Cc: "dev@dpdk.org" , "Lu, Wenzhuo" Message-ID: <20170105085203.GL12822@6wind.com> References: <1483084390-53159-1-git-send-email-wei.zhao1@intel.com> <1483084390-53159-15-git-send-email-wei.zhao1@intel.com> <20170103140759.GA12822@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v2 14/18] net/ixgbe: parse L2 tunnel filter X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 08:52:11 -0000 On Thu, Jan 05, 2017 at 03:12:01AM +0000, Zhao1, Wei wrote: > Hi, adrien > > > -----Original Message----- > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > Sent: Tuesday, January 3, 2017 10:08 PM > > To: Zhao1, Wei > > Cc: dev@dpdk.org; Lu, Wenzhuo > > 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: > > > 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 > > > > 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. > > 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