From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id AE9151F5 for ; Wed, 20 Sep 2017 12:33:01 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 03:33:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,421,1500966000"; d="scan'208";a="902166282" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by FMSMGA003.fm.intel.com with ESMTP; 20 Sep 2017 03:32:59 -0700 To: "Zhao1, Wei" , "dev@dpdk.org" References: <20170824032602.107045-1-wei.zhao1@intel.com> <20170824032602.107045-2-wei.zhao1@intel.com> <4e3ff030-ddfe-ed0d-7668-def8f0d49f43@intel.com> From: Ferruh Yigit Message-ID: <84dc6473-9193-5df5-168b-36fad18c1f6a@intel.com> Date: Wed, 20 Sep 2017 11:32:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 1/2] net/i40e: queue region set and flush X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 10:33:03 -0000 On 9/20/2017 4:20 AM, Zhao1, Wei wrote: > Hi, Ferruh > >> -----Original Message----- >> From: Yigit, Ferruh >> Sent: Friday, September 15, 2017 7:01 PM >> To: Zhao1, Wei ; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH 1/2] net/i40e: queue region set and flush >> >> On 9/6/2017 10:11 AM, Ferruh Yigit wrote: >>> On 9/1/2017 3:38 AM, Zhao1, Wei wrote: >>>> HI, Ferruh >>>> >>>>> -----Original Message----- >>>>> From: Yigit, Ferruh >>>>> Sent: Friday, September 1, 2017 12:18 AM >>>>> To: Zhao1, Wei ; dev@dpdk.org >>>>> Subject: Re: [dpdk-dev] [PATCH 1/2] net/i40e: queue region set and >>>>> flush >>>>> >>>>> On 8/24/2017 4:26 AM, Wei Zhao wrote: >>>>>> This feature enable queue regions configuration for RSS in PF/VF, >>>>>> so that different traffic classes or different packet >>>>>> classification types can be separated to different queues in >>>>>> different queue regions.This patch can set queue region range, it >>>>>> include queue number in a region and the index of first queue. >>>>>> This patch enable mapping between different priorities (UP) and >>>>>> different traffic classes.It also enable mapping between a region >>>>>> index and a sepcific flowtype(PCTYPE).It also provide the solution >>>>>> of flush all configuration about queue region the above described. >>>>>> >>>>>> Signed-off-by: Wei Zhao >>>>> >>>>> Hi Wei, >>>>> >>>>> I wonder if this can be implemented using rte_flow, instead of PMD >>>>> specific API? >>>>> >>>>> And if not, what is missing in rte_flow for this? >>>> >>>> Yes, at first I have plan to use rte_flow to implement this feature. >>>> But there are many opposition for this, for example, this feature is >>>> only support by i40e but not igb/ixgbe From hardware capacity, not all NIC. >> So, private API is selected. >>> >>> I guess rte_flow headers needs to be updated for this support, how big >>> that update, what is missing in rte_flow for this? >> >> Hi Wei, >> >> Would you mind answering this? > > If we want rte_flow also to support this feature, > although there will be many new CLI command need to be Add to testpmd app, > and some code change in ethdev, for example add new member in enum rte_filter_type and so on. new CLI part is side effect of the rte_flow, to demonstrate how to use flow modes. I was more interested in how much change required in rte_flow header. > But the biggest problem is to get recognize and support from expert and authority in DPDK community for this new change. Is this is referring previous push back for rte_filter_type update, I think this can be evaluated case by case. As far as I remember previously it is rejected in favor of improving rte_flow, this time update is required to be able to use rte_flow, so I assume can be OK. I believe this can be discussed out of this patch scope. > By now, rte_flow has no support for rss config application, but only filter configuration. But maybe this can be a work in next release. At least it is good that this effort can be re-used later for rte_flow, I still believe this option worth investigating for further releases. > > >> >> Thanks, >> ferruh >> >>> >>> Even this is only for i40e, rte_flow can be an option. I believe this >>> increases the usability of the feature for the driver. >>> >>>> >>>>> >>>>> Thanks, >>>>> ferruh >>> >