From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhao1, Wei" Subject: Re: [PATCH v2 01/25] ethdev: introduce generic flow API Date: Mon, 23 Oct 2017 08:53:49 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , Adrien Mazarguil To: Adrien Mazarguil 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) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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!