From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: Survey for final decision about per-port offload API Date: Tue, 24 Apr 2018 17:18:05 +0100 Message-ID: <7d0f5464-03a9-00db-307e-08d55b88a903@intel.com> References: <2759953.P7QpFFSjiU@xps> <2601191342CEEE43887BDE71AB977258AEA520B2@IRSMSX102.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258AEA5344F@IRSMSX102.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Ajit Khaparde , Jerin Jacob , Shijith Thotton , Santosh Shukla , Rahul Lakkireddy , John Daley , "Lu, Wenzhuo" , "Xing, Beilei" , "Zhang, Qi Z" , "Wu, Jingjing" , Adrien Mazarguil , Nelio Laranjeiro , Yongseok Koh , Shahaf Shuler , Tomasz Duszynski , Jianbo Liu , Alejandro Lucero , Hemant Agrawal , Shreyansh Jain , Harish Patil , Rasesh Mody , Andrew To: "Ananyev, Konstantin" , Thomas Monjalon , "dev@dpdk.org" Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 83D082BCD for ; Tue, 24 Apr 2018 18:18:13 +0200 (CEST) In-Reply-To: <2601191342CEEE43887BDE71AB977258AEA5344F@IRSMSX102.ger.corp.intel.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 4/24/2018 4:20 PM, Ananyev, Konstantin wrote: > > >> -----Original Message----- >> From: Yigit, Ferruh >> Sent: Tuesday, April 24, 2018 1:28 PM >> To: Ananyev, Konstantin ; Thomas Monjalon ; dev@dpdk.org >> Cc: Ajit Khaparde ; Jerin Jacob ; Shijith Thotton >> ; Santosh Shukla ; Rahul Lakkireddy >> ; John Daley ; Lu, Wenzhuo ; Xing, Beilei >> ; Zhang, Qi Z ; Wu, Jingjing ; Adrien Mazarguil >> ; Nelio Laranjeiro ; Yongseok Koh ; Shahaf Shuler >> ; Tomasz Duszynski ; Jianbo Liu ; Alejandro Lucero >> ; Hemant Agrawal ; Shreyansh Jain ; Harish >> Patil ; Rasesh Mody ; Andrew Rybchenko ; >> Shrikrishna Khare ; Maxime Coquelin ; Legacy, Allain (Wind River) >> ; Richardson, Bruce ; Gaetan Rivet ; Olivier Matz >> >> Subject: Re: [dpdk-dev] Survey for final decision about per-port offload API >> >> On 4/24/2018 12:08 PM, Ananyev, Konstantin wrote: >>> Hi Ferruh, >>> >>>> >>>> On 3/30/2018 2:47 PM, Thomas Monjalon wrote: >>>>> There are some discussions about a specific part of the offload API: >>>>> "To enable per-port offload, the offload should be set on both >>>>> device configuration and queue setup." >>>>> >>>>> It means the application must repeat the port offload flags >>>>> in rte_eth_conf.[rt]xmode.offloads and rte_eth_[rt]xconf.offloads, >>>>> when calling respectively rte_eth_dev_configure() and >>>>> rte_eth_[rt]x_queue_setup for each queue. >>>>> >>>>> The PMD must check if there is mismatch, i.e. a port offload not >>>>> repeated in queue setup. >>>>> There is a proposal to do this check at ethdev level: >>>>> http://dpdk.org/ml/archives/dev/2018-March/094023.html >>>>> >>>>> It was also proposed to relax the API and allow "forgetting" port >>>>> offloads in queue offloads: >>>>> http://dpdk.org/ml/archives/dev/2018-March/092978.html >>>>> >>>>> It would mean the offloads applied to a queue result of OR operation: >>>>> rte_eth_conf.[rt]xmode.offloads | rte_eth_[rt]xconf.offloads >>>>> >>>>> 1/ Do you agree with above API change? >>>> >>>> There is a detail of ability to disabling queue level offloads in queue_setup() >>>> function, I want to discuss here. >>>> >>>> Prolog: >>>> port level offload: An offload only can be applied port level, to all queues. >>>> queue level offload: An offload can be applied into individual queues of the port >>>> >>>> PMD reports port offload capability: port level offload + queue level offload >>>> PMD reports queue offload capability: queue level offload >>>> >>>> >>>> Above suggested change to API: >>>> - Application will be limited in configure() to set only an offload within "port >>>> offload capability" >>>> - Application will be limited in queue_setup() to set only an offload within >>>> "queue offload capability" >>>> >>>> >>>> This doesn't say much about disabling an offload in queue_setup(), as a rule: >>>> - An "port level offload" can't be disabled in queue_setup() >>>> >>>> >>>> There are two cases of disable: >>>> 1- Disabling a "queue level offload" enabled queue_setup() previously >>>> 2- Disabling a "queue level offload" enabled in configure() >>>> >>>> If second is not supported, to disable the offload, applications should >>>> stop->re-configure()->re-queue_setup()->start the port. But having this >>>> capability makes the offloading parameters more confusing for applications. >>>> >>>> >>>> I suggest adding disable support to fist one but not second one. >>> >>> Not sure why to introduce such limitation? >> >> Not supporting second one? >> >> To differentiate disable request for that case is harder. How can we say to >> disable a "queue level offloads" enabled by configure()? >> >> It may be by setting these offloads in queue_setup() as well and when any >> offload is missing in queue_setup() it can be taken as disable request. This >> forces applications to duplicate/set "queue level offloads" enabled by >> configure() in the queue_setup() function by default. >> >> This is an option, but my concern was to this may be harder to manage by >> applications. >> An application will have to remove "port level offload" from port_offloads and >> feed it into each queue_setup(). >> >> Also this is closer to existing API but not same, the difference is >> queue_setup() doesn't get "port level offload" >> >> We can go with this one if there is a requirement for it. >> >> And if we prefer to go with this option, perhaps we can think twice about >> changing exiting API because this will be very close the existing API. Only >> logically it is not correct to force application to set some offloads in >> queue_setup() for the PMD that doesn't support queue offload at all, this can be >> handled in PMD, and saves us of all the trouble of the change. > > I suppose both ways are possible - though if we don't allow user to disable queue-specific > offload on particular queue, we would end up with most users just not specifying > any queue-specific offloads at configure() at all - just to have an ability to disable it in future > for particular queue. Yes, this has been mentioned as a easier option to go previously. > > Konstantin > >