[dpdk-dev] [PATCH v2 01/25] ethdev: introduce generic flow API

Zhao1, Wei wei.zhao1 at intel.com
Mon Oct 23 10:53:49 CEST 2017


Hi, Adrien



> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Adrien Mazarguil
> Sent: Saturday, December 17, 2016 12:25 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 01/25] ethdev: introduce generic flow API
> 
> 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 process and
> validate flow rules.
> 
> Benefits:
> 
> - 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.
> 
> - The behavior of a flow rule is the same regardless of the underlying
>   device, applications do not need to be aware of hardware quirks.
> 
> - Extensible by design, API/ABI breakage should rarely occur if at all.
> 
> - Documentation is self-standing, no need to look up elsewhere.
> 
> Existing filter types will be deprecated and removed in the near future.
> 
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil at 6wind.com>
> ---
>  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(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 26d9590..5975cff 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -243,6 +243,10 @@ M: Thomas Monjalon
> <thomas.monjalon at 6wind.com>
>  F: lib/librte_ether/
>  F: scripts/test-null.sh
> 

+/**
+ * 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 
+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_rss_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!



More information about the dev mailing list