[dpdk-dev] Survey for final decision about per-port offload API

Ferruh Yigit ferruh.yigit at intel.com
Tue Apr 24 18:18:05 CEST 2018


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 <konstantin.ananyev at intel.com>; Thomas Monjalon <thomas at monjalon.net>; dev at dpdk.org
>> Cc: Ajit Khaparde <ajit.khaparde at broadcom.com>; Jerin Jacob <jerin.jacob at caviumnetworks.com>; Shijith Thotton
>> <shijith.thotton at cavium.com>; Santosh Shukla <santosh.shukla at caviumnetworks.com>; Rahul Lakkireddy
>> <rahul.lakkireddy at chelsio.com>; John Daley <johndale at cisco.com>; Lu, Wenzhuo <wenzhuo.lu at intel.com>; Xing, Beilei
>> <beilei.xing at intel.com>; Zhang, Qi Z <qi.z.zhang at intel.com>; Wu, Jingjing <jingjing.wu at intel.com>; Adrien Mazarguil
>> <adrien.mazarguil at 6wind.com>; Nelio Laranjeiro <nelio.laranjeiro at 6wind.com>; Yongseok Koh <yskoh at mellanox.com>; Shahaf Shuler
>> <shahafs at mellanox.com>; Tomasz Duszynski <tdu at semihalf.com>; Jianbo Liu <jianbo.liu at arm.com>; Alejandro Lucero
>> <alejandro.lucero at netronome.com>; Hemant Agrawal <hemant.agrawal at nxp.com>; Shreyansh Jain <shreyansh.jain at nxp.com>; Harish
>> Patil <harish.patil at cavium.com>; Rasesh Mody <rasesh.mody at cavium.com>; Andrew Rybchenko <arybchenko at solarflare.com>;
>> Shrikrishna Khare <skhare at vmware.com>; Maxime Coquelin <maxime.coquelin at redhat.com>; Legacy, Allain (Wind River)
>> <allain.legacy at windriver.com>; Richardson, Bruce <bruce.richardson at intel.com>; Gaetan Rivet <gaetan.rivet at 6wind.com>; Olivier Matz
>> <olivier.matz at 6wind.com>
>> 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
> 
> 



More information about the dev mailing list