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 73D662BC9 for ; Fri, 26 Feb 2016 02:18:04 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 25 Feb 2016 17:18:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,498,1449561600"; d="scan'208";a="921394940" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga002.jf.intel.com with ESMTP; 25 Feb 2016 17:18:03 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 25 Feb 2016 17:18:02 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 25 Feb 2016 17:18:02 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.132]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.42]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 09:18:00 +0800 From: "Wu, Jingjing" To: Thomas Monjalon , Rahul Lakkireddy Thread-Topic: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir Thread-Index: AQHRbxHAE9IELzdP9kibpzspf6wEfp86xJEAgAA8v4CAADzeAIAAvLcAgACUgACAAPCScA== Date: Fri, 26 Feb 2016 01:17:59 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F8DC9E41@SHSMSX104.ccr.corp.intel.com> References: <3102616.xnBgmsEaQs@xps13> <20160225093322.GB10077@chelsio.com> <3876623.1zX8JlhDJf@xps13> In-Reply-To: <3876623.1zX8JlhDJf@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDg4OWZiZDgtYTg0MC00NDVkLTkzNWItMmM0YWFmY2M3MWQzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Imszdys0YnNlT2EwSUp2WXNGKzdKWTZBVWdEYXRrS1lOQ3JyXC9wSzRaMkljPSJ9 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" , Kumar A S , Nirranjan Kirubaharan Subject: Re: [dpdk-dev] [PATCH 01/10] ethdev: add a generic 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: Fri, 26 Feb 2016 01:18:05 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, February 26, 2016 2:25 AM > To: Rahul Lakkireddy > Cc: Richardson, Bruce ; dev@dpdk.org; Kumar A= S > ; Nirranjan Kirubaharan ; Wu,= Jingjing > > Subject: Re: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new = behavior switch > to fdir >=20 > 2016-02-25 15:03, Rahul Lakkireddy: > > On Wednesday, February 02/24/16, 2016 at 14:17:58 -0800, Thomas Monjalo= n wrote: > > > > A raw flow provides a generic way for vendors to add their vendor > > > > specific input flow. > > > > > > Please, "generic" and "vendor specific" in the same sentence. > > > It's obviously wrong. > > > > I think this sentence is being mis-interpreted. > > What I intended to say is: the fields are generic so that any vendor ca= n > > hook-in. The fields themselves are not vendor specific. >=20 > We are trying to push some features into fields of an API instead of > thinking how to make it simple. >=20 > > > > In our case, it is possible to match several flows > > > > in a single rule. For example, it's possible to set an ethernet, v= lan, > > > > ip and tcp/udp flows all in a single rule. We can specify all of t= hese > > > > flows in a single raw input flow, which can then be passed to cxgbe= flow > > > > director to set the corresponding filter. > > > > > > I feel we need to define what is an API. > > > If the application wants to call something specific to the NIC, why u= sing > > > the ethdev API? You just have to include cxgbe.h. > > > > Well, in that sense, flow-director is also very intel specific, no ? >=20 > Yes. I think the term "flow director" comes from Intel. >=20 > > What we are trying to do is make flow-director generic >=20 > So let's stop calling it flow director. > We are talking about filtering, right? >=20 Hi Thomas Are you suggesting chelsio to define a new filter type? > Why is it so complex? We are talking about packet filtering, not rocket s= cience! > The complex is due to different NICs different behavior :-) As I know, it is a common way to use used-define data pass specific infor t= o driver. Even flow director is concept from Intel's NIC, but I think it is the gener= ic one comparing with other kinds of filters. So I think that's why Rahul choose it to add t= heir kind of filters. As I know enic driver also uses flow director API to support their filters. No matter chelsio NIC filter uses flow director API or define another new f= ilter type. I vote the change happened in struct rte_eth_fdir_input, it provide a RAW Flow typ= e, And there is also a mask field for that, by this way, user can have a flexi= ble way to configure. And drivers can parse the raw input to define the filter fields. But for the change happened in struct rte_eth_fdir_action, only SWITCH type= is added, Where to switch? All things is in behavior_arg[RTE_ETH_BEHAVIOR_ARG_MAX_LEN= ] which is black to user. Maybe your previous define in RFC makes more sense.= It's better to add user defined field but not for all args. Any better suggestion?