From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <beilei.xing@intel.com>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
by dpdk.org (Postfix) with ESMTP id E9F48106A
for <dev@dpdk.org>; Thu, 8 Dec 2016 10:00:24 +0100 (CET)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
by orsmga105.jf.intel.com with ESMTP; 08 Dec 2016 01:00:23 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,318,1477983600"; d="scan'208";a="910007565"
Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204])
by orsmga003.jf.intel.com with ESMTP; 08 Dec 2016 01:00:23 -0800
Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by
FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Thu, 8 Dec 2016 01:00:10 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Thu, 8 Dec 2016 01:00:09 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.206]) by
SHSMSX151.ccr.corp.intel.com ([169.254.3.116]) with mapi id 14.03.0248.002;
Thu, 8 Dec 2016 17:00:05 +0800
From: "Xing, Beilei" <beilei.xing@intel.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>, "dev@dpdk.org"
<dev@dpdk.org>
CC: Thomas Monjalon <thomas.monjalon@6wind.com>, "De Lara Guarch, Pablo"
<pablo.de.lara.guarch@intel.com>, Olivier Matz <olivier.matz@6wind.com>
Thread-Topic: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API
Thread-Index: AQHSQCYA6uPnKzV+6EK5TAIQEgT0dqD93jGA
Date: Thu, 8 Dec 2016 09:00:05 +0000
Message-ID: <94479800C636CB44BD422CB454846E012EA36991@SHSMSX101.ccr.corp.intel.com>
References: <cover.1471632644.git.adrien.mazarguil@6wind.com>
<cover.1479309719.git.adrien.mazarguil@6wind.com>
<1c8a8e4fec73ed33836f1da9525b1b8b53048518.1479309720.git.adrien.mazarguil@6wind.com>
In-Reply-To: <1c8a8e4fec73ed33836f1da9525b1b8b53048518.1479309720.git.adrien.mazarguil@6wind.com>
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
Subject: Re: [dpdk-dev] [PATCH 01/22] 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: Thu, 08 Dec 2016 09:00:25 -0000
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Adrien Mazarguil
> Sent: Thursday, November 17, 2016 12:23 AM
> To: dev@dpdk.org
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; De Lara Guarch,
> Pablo <pablo.de.lara.guarch@intel.com>; Olivier Matz
> <olivier.matz@6wind.com>
> Subject: [dpdk-dev] [PATCH 01/22] 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 +
> lib/librte_ether/Makefile | 3 +
> lib/librte_ether/rte_eth_ctrl.h | 1 +
> lib/librte_ether/rte_ether_version.map | 10 +
> lib/librte_ether/rte_flow.c | 159 +++++
> lib/librte_ether/rte_flow.h | 947 +++++++++++++++++++++++++++=
+
> lib/librte_ether/rte_flow_driver.h | 177 ++++++
> 7 files changed, 1301 insertions(+)
>=20
> +/**
> + * RTE_FLOW_ITEM_TYPE_ETH
> + *
> + * Matches an Ethernet header.
> + */
> +struct rte_flow_item_eth {
> + struct ether_addr dst; /**< Destination MAC. */
> + struct ether_addr src; /**< Source MAC. */
> + unsigned int type; /**< EtherType. */
Hi Adrien,
ETHERTYPE in ether header is 2 bytes, so I think "uint16_t type" is more ap=
propriate here, what do you think?
Thanks,
Beilei Xing
> +};
> +