From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id A76323975 for ; Thu, 28 Aug 2014 05:26:16 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 27 Aug 2014 20:30:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,415,1406617200"; d="scan'208";a="590932732" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga002.fm.intel.com with ESMTP; 27 Aug 2014 20:30:15 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 27 Aug 2014 20:30:15 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 27 Aug 2014 20:30:14 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.17]) by shsmsx102.ccr.corp.intel.com ([169.254.2.246]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 11:30:13 +0800 From: "Wu, Jingjing" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl Thread-Index: AQHPwZyfQaobU/kb/0yOC0EzU412AZvj+3OAgAFZloA= Date: Thu, 28 Aug 2014 03:30:13 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F8ADBEF0@SHSMSX104.ccr.corp.intel.com> References: <1409105634-29980-1-git-send-email-jingjing.wu@intel.com> <1409105634-29980-3-git-send-email-jingjing.wu@intel.com> <3024593.z48vgEy6Ts@xps13> In-Reply-To: <3024593.z48vgEy6Ts@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 v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl 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, 28 Aug 2014 03:26:17 -0000 HI, Thomas Just as zhang, helin's said in his pacth "[dpdk-dev] [PATCH 2/5] ethdev: ad= d new ops of 'check_command_supported' and 'rx_classification_filter_ctl'": 'rx_classification_filter_ctl' is for receive classification filter configu= ring. e.g. hash function configuration, flow director configuration. It is = a common API where a lot of commands can be implemented for different sub f= eatures. We want to implement several common API for NIC specific features, to avoid= creating quite a lot of ops in 'struct eth_dev_ops'. The idea came from io= ctl. Because about flow director feature, there is large gap between i40e and ix= gbe. The existed flow director APIs looks specific to IXGBE, so I choose th= is new API to implement i40e's flow director feature. Here, I briefly describe how the new 'rx_classification_filter_ctl' works: The API is like below: typedef int (*eth_rx_classification_filter_ctl_t)(struct rte_eth_dev *dev, enum rte_eth_command cmd, void *arg); Define a head file called rte_i40e.h in lib/librte_pmd_i40e, which contains= the definition about structures specific to i40e, linked to the arg parame= ters above. Define a head file called rte_eth_features.h in lib/librte_ether, which con= tains the commands' definition linked to cmd parameters above. And if user want to use i40e specific features, then the head file rte_i40e= .h need to be included user's application, for example, test-pmd. And user = can encode these structures and call XXX_ctl API to configure their feature= s. Do you think it make sense? And about the rename things, I will move it to a separate patch. > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, August 27, 2014 10:23 PM > To: Wu, Jingjing > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API > rx_classification_filter_ctl >=20 > Hi Jingjing, >=20 > 2014-08-27 10:13, Jingjing Wu: > > support a new ethdev API rx_classification_filter_ctl for all > > the configuration or queries for receive classification filters. > > this patch supports commands the API used below: > > RTE_CMD_FDIR_RULE_ADD > > RTE_CMD_FDIR_RULE_DEL > > RTE_CMD_FDIR_FLUSH > > RTE_CMD_FDIR_INFO_GET >=20 > Could you explain why existing API (flow director + filters) is not enoug= h? > I'd really like to see a common API for all filtering stuff. >=20 > > -/* for 40G only */ > > -#define ETH_RSS_NONF_IPV4_UDP_SHIFT 31 > > -#define ETH_RSS_NONF_IPV4_TCP_SHIFT 33 > > -#define ETH_RSS_NONF_IPV4_SCTP_SHIFT 34 > > -#define ETH_RSS_NONF_IPV4_OTHER_SHIFT 35 > > -#define ETH_RSS_FRAG_IPV4_SHIFT 36 > > -#define ETH_RSS_NONF_IPV6_UDP_SHIFT 41 > > -#define ETH_RSS_NONF_IPV6_TCP_SHIFT 43 > > -#define ETH_RSS_NONF_IPV6_SCTP_SHIFT 44 > > -#define ETH_RSS_NONF_IPV6_OTHER_SHIFT 45 > > -#define ETH_RSS_FRAG_IPV6_SHIFT 46 > > -#define ETH_RSS_FCOE_OX_SHIFT 48 > > -#define ETH_RSS_FCOE_RX_SHIFT 49 > > -#define ETH_RSS_FCOE_OTHER_SHIFT 50 > > -#define ETH_RSS_L2_PAYLOAD_SHIFT 63 > > +/* Packet Classification Type for 40G only */ > > +#define ETH_PCTYPE_NONF_IPV4_UDP 31 > > +#define ETH_PCTYPE_NONF_IPV4_TCP 33 > > +#define ETH_PCTYPE_NONF_IPV4_SCTP 34 > > +#define ETH_PCTYPE_NONF_IPV4_OTHER 35 > > +#define ETH_PCTYPE_FRAG_IPV4 36 > > +#define ETH_PCTYPE_NONF_IPV6_UDP 41 > > +#define ETH_PCTYPE_NONF_IPV6_TCP 43 > > +#define ETH_PCTYPE_NONF_IPV6_SCTP 44 > > +#define ETH_PCTYPE_NONF_IPV6_OTHER 45 > > +#define ETH_PCTYPE_FRAG_IPV6 46 > > +#define ETH_PCTYPE_FCOE_OX 48 /* not used */ > > +#define ETH_PCTYPE_FCOE_RX 49 /* not used */ > > +#define ETH_PCTYPE_FCOE_OTHER 50 /* not used */ > > +#define ETH_PCTYPE_L2_PAYLOAD 63 >=20 > Why is it specific to i40e? Could we have something generic? > Please take care at having only generic things in librte_ether. >=20 > By the way, these renamings should be in a separated patch. >=20 > -- > Thomas