[dpdk-dev] [PATCH v2 14/18] net/ixgbe: parse L2 tunnel filter

Zhao1, Wei wei.zhao1 at intel.com
Thu Jan 5 04:12:01 CET 2017


Hi, adrien

> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Tuesday, January 3, 2017 10:08 PM
> To: Zhao1, Wei <wei.zhao1 at intel.com>
> Cc: dev at dpdk.org; Lu, Wenzhuo <wenzhuo.lu at intel.com>
> 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 <wei.zhao1 at intel.com>
> > Signed-off-by: Wenzhuo Lu <wenzhuo.lu at intel.com>
> >
> > ---
> >
> > 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.


> 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 at 6wind.com
> 
> --
> Adrien Mazarguil
> 6WIND


More information about the dev mailing list