[dpdk-dev] [PATCH] eal: change max hugepage sizes to 4

Burakov, Anatoly anatoly.burakov at intel.com
Mon Aug 12 11:43:46 CEST 2019

On 08-Aug-19 8:31 AM, Thomas Monjalon wrote:
> 07/08/2019 15:28, Hemant Agrawal:
>> HI Thomas,
>>>>> DPDK currently is supporting maximum 3 hugepage, sizes whereas
>>>>> system can support more than this e.g.
>>>>> 64K, 2M, 32M and 1G.
>>>> You can mention ARM platform here, and that this issue starts with
>>>> kernel 5.2 (and I would try to mention this in the title as well).
>>>> This is better than an annotation that will be lost.
>>>>> Having these four hugepage sizes available to use by DPDK, which is
>>>>> valid in case of '--in-memory' EAL option or using 4 separate mount
>>>>> points for each hugepage size;
>>>>> hugepage_info_init() API reports an error.
>>>> Can you describe what is the impact from a user point of view rather
>>>> than mentioning this internal function?
>>> Yes please, we need to understand how much it is critical.
>>> Should we Cc stable at dpdk.org for backport?
>>> Should it be merged at the last minute in 19.08?
>> VPP usages in-memory option. So, VPP on ARM with kernel 5.2 wont' work without this patch.
> Do you want to send a v2 with a better explanation?
> I would suggest to restrict the change to Arm only with an ifdef,
> in order to limit the risk for this release.
> We can think about a dynamic hugepage scan in the next release.

I don't see how this is necessary. The 3 is an arbitrary number here, 
and the ABI isn't broken as this is an internal structure. We could 
increase it to 16 for all i care, and it wouldn't make any difference to 
the rest of the code - we never populate more than we can find anyway.


More information about the dev mailing list