[dpdk-dev] [PATCH 1/3] ethdev: add max burst size to device info

[Shreyansh Jain]

On Wednesday 13 December 2017 06:22 PM, Ananyev, Konstantin wrote:
> 
> 
>> -----Original Message-----
>> From: Shreyansh Jain [mailto:shreyansh.jain at nxp.com]
>> Sent: Tuesday, December 12, 2017 1:44 PM
>> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>; Matan Azrad <matan at mellanox.com>; Nikhil Agarwal
>> <nikhil.agarwal at linaro.org>
>> Cc: dev at dpdk.org; Hunt, David <david.hunt at intel.com>; nikhil.agarwal at nxp.com; hemant.agrawal at nxp.com; Yigit, Ferruh
>> <ferruh.yigit at intel.com>
>> Subject: Re: [PATCH 1/3] ethdev: add max burst size to device info
>>

[...]

>>>> Doesn't such like devices PMDs should try to retrieve multiple HW burst to adjust the asked received  packet number?
>>>
>>> Same thought here...
>>> Can't that limitation be hidden inside PMD by calling HW burst multiple times?
>>
>> This might be required in some cases for performance.
>> It is possible that for each request containing N buffers, if the PMD
>> fetches all N (more than its preferred burst_size), cache misses reduce
>> the performance - especially for SoC with limited cache size.
>>
>> Also, a complete cycle of
>> application->driver->hardware->driver->application can help driver
>> prefetch buffers - which, in case of hw burst looping, might be too
>> little to complete the prefetch cycle.
>>
>> To summarize, indeed this is for performance specific cases and the idea
>> that @Matan gave for renaming 'perf_buf_size' to highlight this, sounds
>> logical.
>>
>>> Also if I am not mistaken - it would increase size of struct rte_eth_dev_info, right?
>>> If so, then it means ABI breakage.
>>
>> Yes, deprecation notice should have been sent - if we continue with the
>> dev_info change. To me that looks as one of the option. Maybe, someone
>> on the list has a better idea.
> 
> In theory there is at least 2 free bytes at the end of struct rte_eth_desc_lim.
> Might be it would help a bit.

:) Thanks for highlighting.
So, you feel it is OK to reuse this assumption of hole in alignment? It 
certainly would bypass the ABI limitation but not sure which cases it 
would break (for example, same assumptions by others)

It would an issue in case of 32bit systems, though.

[...]

-
Shreyansh