From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <jingjing.wu@intel.com>
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
by dpdk.org (Postfix) with ESMTP id 121FE8D9F
for <dev@dpdk.org>; Wed, 13 Jan 2016 14:16:39 +0100 (CET)
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
by fmsmga104.fm.intel.com with ESMTP; 13 Jan 2016 05:16:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.22,289,1449561600"; d="scan'208";a="880499764"
Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205])
by fmsmga001.fm.intel.com with ESMTP; 13 Jan 2016 05:16:38 -0800
Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by
fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Wed, 13 Jan 2016 05:16:38 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Wed, 13 Jan 2016 05:16:38 -0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.117]) by
SHSMSX103.ccr.corp.intel.com ([169.254.4.218]) with mapi id 14.03.0248.002;
Wed, 13 Jan 2016 21:16:36 +0800
From: "Wu, Jingjing" <jingjing.wu@intel.com>
To: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Thread-Topic: [dpdk-dev] [RFC v2 1/2] ethdev: add packet filter flow and new
behavior switch to fdir
Thread-Index: AQHRTd9pVA90aW93N0O3H4GhTLSjCp75ZXTA
Date: Wed, 13 Jan 2016 13:16:36 +0000
Message-ID: <9BB6961774997848B5B42BEC655768F8D80272@SHSMSX104.ccr.corp.intel.com>
References: <cover.1450448999.git.rahul.lakkireddy@chelsio.com>
<ba130385fe9b7af56d558d0e486a43c6e52ca169.1450448999.git.rahul.lakkireddy@chelsio.com>
<9BB6961774997848B5B42BEC655768F8D74B6B@SHSMSX104.ccr.corp.intel.com>
<20160113084920.GA6469@scalar.blr.asicdesigners.com>
In-Reply-To: <20160113084920.GA6469@scalar.blr.asicdesigners.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2Y1NWIwMmUtY2ZhZi00NzYyLWE1Y2MtMGI5MmUzOWJkM2RlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjQuMTAuMTkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQ1ptT3NudGNFNE1LSk8wRmx3S0NWWGtNRzRmQkRNOHJiaXlcL2RJditkQ3c9In0=
x-ctpclassification: CTP_IC
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>, Felix Marti <felix@chelsio.com>,
Nirranjan Kirubaharan <nirranjan@chelsio.com>, Kumar A S <kumaras@chelsio.com>
Subject: Re: [dpdk-dev] [RFC v2 1/2] ethdev: add packet filter flow and new
behavior switch to fdir
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <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: Wed, 13 Jan 2016 13:16:40 -0000
Hi, Rahul
> -----Original Message-----
> From: Rahul Lakkireddy [mailto:rahul.lakkireddy@chelsio.com]
> Sent: Wednesday, January 13, 2016 4:49 PM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Felix Marti; Kumar A S; Nirranjan Kirubaharan
> Subject: Re: [dpdk-dev] [RFC v2 1/2] ethdev: add packet filter flow and n=
ew behavior
> switch to fdir
>=20
> Hi Jingjing,
>=20
> On Tuesday, January 01/12/16, 2016 at 17:12:47 -0800, Wu, Jingjing wrote:
> > >
> > > diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_e=
th_ctrl.h
> > > index ce224ad..5cc22a0 100644
> > > --- a/lib/librte_ether/rte_eth_ctrl.h
> > > +++ b/lib/librte_ether/rte_eth_ctrl.h
> > > @@ -74,7 +74,11 @@ extern "C" {
> > > #define RTE_ETH_FLOW_IPV6_EX 15
> > > #define RTE_ETH_FLOW_IPV6_TCP_EX 16
> > > #define RTE_ETH_FLOW_IPV6_UDP_EX 17
> > > -#define RTE_ETH_FLOW_MAX 18
> > > +#define RTE_ETH_FLOW_PKT_FILTER_IPV4_TCP 18 #define
> > > +RTE_ETH_FLOW_PKT_FILTER_IPV4_UDP 19 #define
> > > +RTE_ETH_FLOW_PKT_FILTER_IPV6_TCP 20 #define
> > > +RTE_ETH_FLOW_PKT_FILTER_IPV6_UDP 21
> > > +#define RTE_ETH_FLOW_MAX 22
> > >
> > How to distinguish RTE_ETH_FLOW_PKT_FILTER_IPV4_XX with
> RTE_ETH_FLOW_NONFRAG_IPV4_XX, what is the difference?
>=20
> The packet filter flow is basically a superset containing Ethernet,
> vlan, ipv4/ipv6 and tcp/udp flows whose fields can all be matched at
> the same time, unlike in case of the current flow director which seems
> to match only one of the flows at any given time. Additionally, it also
> allows specifying masks. I separated the two to make this meaning
> explicit. If this is not necessary, then I will merge them.
Thanks for clarification, now I understand. How about just define one to in=
dicate using pkt_filter?
And move the IPV4_XX info to the structure rte_eth_pkt_filter?
> > There is also a patch http://dpdk.org/dev/patchwork/patch/9661/ which a=
dded these
> fields. Maybe we can merge them together.
>=20
> Yes, we can merge them. Would you like me to merge your patch here?
The i40e driver implementation is done based on the change. If you'd like t=
o merge,
maybe other patches in the patch set also need to be merged. Anyway, I thin=
k
maintainer can deal with it.=20
>=20
> The current rte_eth_XX_flow only allow matching _one_ of the flows
> because of the union. In contrast, rte_eth_pkt_filter_flow can match
> several flows at the same time; i.e. it can match ethernet, vlan, ip,
> and tcp/udp all at the same time. rte_eth_pkt_filter_flow is basically
> a superset containing several flows that can be matched at the same
> time.
>=20
> In our Chelsio T5 hardware, it's possible to have several flows that can
> be matched in a single rule. This is why I've created a superset that
> can match several flows in the same rule.
>=20
> Thanks,
> Rahul
Thanks for clarification, it's clear. And it's great to have this feature.
Even it is a superset containing several flows, we still can use the
existing structs like
struct rte_eth_ipv4_flow {
struct rte_eth_l2_flow ether;
struct rte_eth_vlan_flow vlan;
uint32_t src_ip;
uint32_t dst_ip;
};
What do you think?
Thanks
Jingjing