From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 121FE8D9F for ; 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" To: Rahul Lakkireddy 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: <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" , Felix Marti , Nirranjan Kirubaharan , Kumar A S 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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