From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id A6E9E1B351 for ; Mon, 23 Oct 2017 10:53:57 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP; 23 Oct 2017 01:53:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,422,1503385200"; d="scan'208";a="141175370" Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86]) by orsmga004.jf.intel.com with ESMTP; 23 Oct 2017 01:53:55 -0700 Received: from pgsmsx110.gar.corp.intel.com (10.221.44.111) by KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 23 Oct 2017 16:53:50 +0800 Received: from pgsmsx103.gar.corp.intel.com ([169.254.2.203]) by PGSMSX110.gar.corp.intel.com ([169.254.13.155]) with mapi id 14.03.0319.002; Mon, 23 Oct 2017 16:53:49 +0800 From: "Zhao1, Wei" To: Adrien Mazarguil CC: "dev@dpdk.org" , Adrien Mazarguil Thread-Topic: [dpdk-dev] [PATCH v2 01/25] ethdev: introduce generic flow API Thread-Index: AQHSV7karC67xeKr+0C4PWEofdS44KLzBktg Date: Mon, 23 Oct 2017 08:53:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [172.30.20.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 01/25] ethdev: introduce generic flow API 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: Mon, 23 Oct 2017 08:53:58 -0000 Hi, Adrien > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Adrien Mazarguil > Sent: Saturday, December 17, 2016 12:25 AM > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH v2 01/25] ethdev: introduce generic flow API >=20 > This new API supersedes all the legacy filter types described in rte_eth_= ctrl.h. > It is slightly higher level and as a result relies more on PMDs to proces= s and > validate flow rules. >=20 > Benefits: >=20 > - A unified API is easier to program for, applications do not have to be > written for a specific filter type which may or may not be supported by > the underlying device. >=20 > - The behavior of a flow rule is the same regardless of the underlying > device, applications do not need to be aware of hardware quirks. >=20 > - Extensible by design, API/ABI breakage should rarely occur if at all. >=20 > - Documentation is self-standing, no need to look up elsewhere. >=20 > Existing filter types will be deprecated and removed in the near future. >=20 > Signed-off-by: Adrien Mazarguil > --- > MAINTAINERS | 4 + > doc/api/doxy-api-index.md | 2 + > lib/librte_ether/Makefile | 3 + > lib/librte_ether/rte_eth_ctrl.h | 1 + > lib/librte_ether/rte_ether_version.map | 11 + > lib/librte_ether/rte_flow.c | 159 +++++ > lib/librte_ether/rte_flow.h | 942 +++++++++++++++++++++++++++= + > lib/librte_ether/rte_flow_driver.h | 181 ++++++ > 8 files changed, 1303 insertions(+) >=20 > diff --git a/MAINTAINERS b/MAINTAINERS > index 26d9590..5975cff 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -243,6 +243,10 @@ M: Thomas Monjalon > > F: lib/librte_ether/ > F: scripts/test-null.sh >=20 +/** + * RTE_FLOW_ACTION_TYPE_RSS + * + * Similar to QUEUE, except RSS is additionally performed on packets to + * spread them among several queues according to the provided parameters. + * + * Note: RSS hash result is normally stored in the hash.rss mbuf field, + * however it conflicts with the MARK action as they share the same + * space. When both actions are specified, the RSS hash is discarded=20 +and + * PKT_RX_RSS_HASH is not set in ol_flags. MARK has priority. The mbuf + * structure should eventually evolve to store both. + * + * Terminating by default. + */ +struct rte_flow_action_rss { + const struct rte_eth_rss_conf *rss_conf; /**< RSS parameters. */ + uint16_t num; /**< Number of entries in queue[]. */ + uint16_t queue[]; /**< Queues indices to use. */ }; + I am plan for moving rss to rte_flow. May I ask you some question for this struct of rte_flow_action_rss. 1. why do you use pointer mode for rss_conf, why not use " struct rte_eth_r= ss_conf rss_conf "? we need to fill these rss info which get from CLI to this struct, if we use= the pointer mode, how can we fill in these info? 2. And also why the" const" is not need? We need a const ?How can we config= this parameter? 3. what is your expect mode for CLI command for rss config? When I type in = : " flow create 0 pattern eth / tcp / end actions rss queues queue 0 /end " Or " flow create 0 pattern eth / tcp / end actions rss queues {0 1 2} /end = " I get " Bad arguments ". So, the right CLI command is ? Thank you!