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 sta...@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.
--
Thanks,
Anatoly
