From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <wei.zhao1@intel.com>
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43])
by dpdk.org (Postfix) with ESMTP id A6E9E1B351
for <dev@dpdk.org>; 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" <wei.zhao1@intel.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, Adrien Mazarguil
<adrien.mazarguil@6wind.com>
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: <A2573D2ACFCADC41BB3BE09C6DE313CA07C70341@PGSMSX103.gar.corp.intel.com>
References: <cover.1479309719.git.adrien.mazarguil@6wind.com>
<cover.1481903839.git.adrien.mazarguil@6wind.com>
<f8e97c46b8002ae6d4061e17abd8ff836b8c7cc6.1481903839.git.adrien.mazarguil@6wind.com>
In-Reply-To: <f8e97c46b8002ae6d4061e17abd8ff836b8c7cc6.1481903839.git.adrien.mazarguil@6wind.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <adrien.mazarguil@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(+)
>=20
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 26d9590..5975cff 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -243,6 +243,10 @@ M: Thomas Monjalon
> <thomas.monjalon@6wind.com>
> 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!