From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 2DAB32B9F for ; Thu, 10 Mar 2016 01:54:22 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP; 09 Mar 2016 16:54:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,313,1455004800"; d="scan'208";a="666750528" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by FMSMGA003.fm.intel.com with ESMTP; 09 Mar 2016 16:54:22 -0800 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 9 Mar 2016 16:54:21 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 9 Mar 2016 16:54:20 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.232]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.18]) with mapi id 14.03.0248.002; Thu, 10 Mar 2016 08:54:19 +0800 From: "Lu, Wenzhuo" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v6 2/5] lib/librte_ether: support l2 tunnel operations Thread-Index: AQHReQdK6QGKNeET50qQOU5kJQOG9Z9PuSoAgACTSyCAAAcwAIABhvAQ Date: Thu, 10 Mar 2016 00:54:19 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC090903439A06@shsmsx102.ccr.corp.intel.com> References: <1454051035-25757-1-git-send-email-wenzhuo.lu@intel.com> <1879903.OgO4X0RlNL@xps13> <6A0DE07E22DDAD4C9103DF62FEBC090903439197@shsmsx102.ccr.corp.intel.com> <2524747.83qVv48D0D@xps13> In-Reply-To: <2524747.83qVv48D0D@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v6 2/5] lib/librte_ether: support l2 tunnel operations X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 00:54:22 -0000 Hi Thomas, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, March 9, 2016 5:28 PM > To: Lu, Wenzhuo > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 2/5] lib/librte_ether: support l2 tunne= l > operations >=20 > 2016-03-09 01:15, Lu, Wenzhuo: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > 2016-03-08 14:53, Wenzhuo Lu: > > > > +/** > > > > + * l2 tunnel type. > > > > + */ > > > > +enum rte_eth_l2_tunnel_type { > > > > + RTE_L2_TUNNEL_TYPE_NONE =3D 0, > > > > + RTE_L2_TUNNEL_TYPE_E_TAG, > > > > + RTE_L2_TUNNEL_TYPE_MAX, > > > > +}; > > > > > > We already have rte_eth_tunnel_type. > > Seems the tunnels in rte_eth_tunnel_type are all L3 packets. So, I want= to add > a new type for e-tag, s-tag... as they're l2 packets. > > Do you suggest to merge it into rte_eth_tunnel_type? >=20 > Maybe you can keep the L2 prefix and add it in the same enum. > It depends wether the rest of the API is specific to L2 or not. OK, I'll keep the L2 prefix and merge it to the enum rte_eth_tunnel_type. >=20 > > > Why this struct is in rte_eth_ctrl.h and not used with rte_eth_dev_fi= lter_ctrl? > > Just want to put it together with rte_eth_tunnel_type :) >=20 > > > Why are we still adding some filtering functions after having the > > > assertion that the new filtering API in lib/librte_ether/rte_eth_ctrl= .h was > generic enough? > > > The filtering API v2 was a total failure. > > > Are we going to add new functions each time a new bit of a header > > > must be parsed by an offloaded filtering? > > > Are we going to add new functions for each new filter of a NIC? > > > > Sorry, my bad. I'll try to use the existing filter API. Thanks. >=20 > OK, using the filtering API v2 is better. > But I'm not confident it is a good API. > If you have any concern, please discuss them. Because we need to discuss = how > to make a really generic API which fits with any filtering (flow steering= ) offload > of any vendor while being descriptive enough and easy to use. It's OK for me to use rte_eth_dev_filter_ctrl :)