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

Jerin Jacob Kollanukkaran jerinj at marvell.com
Thu Aug 8 11:00:57 CEST 2019


> -----Original Message-----
> From: David Marchand <david.marchand at redhat.com>
> Sent: Thursday, August 8, 2019 1:03 PM
> To: Hemant Agrawal <hemant.agrawal at nxp.com>
> Cc: Thomas Monjalon <thomas at monjalon.net>; Gagandeep Singh
> <G.Singh at nxp.com>; dev <dev at dpdk.org>; Burakov, Anatoly
> <anatoly.burakov at intel.com>; Olivier Matz <olivier.matz at 6wind.com>;
> Andrew Rybchenko <arybchenko at solarflare.com>; Nipun Gupta
> <nipun.gupta at nxp.com>; Jerin Jacob Kollanukkaran <jerinj at marvell.com>;
> Gavin Hu <gavin.hu at arm.com>; Bruce Richardson
> <bruce.richardson at intel.com>
> Subject: [EXT] Re: [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4
> On Wed, Aug 7, 2019 at 3:28 PM Hemant Agrawal <hemant.agrawal at nxp.com>
> wrote:
> >
> > 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.
> >
> 
> I have been looking at the changes in the linux kernel.
> Can you pinpoint at the commit that changed this in 5.2?
> 
> I can see a change in the code, but in 5.0, or maybe something changed in the
> configuration.
> 
> The patch you propose is not that risky (x86 supports two pagesizes, and max
> hugepage is already at 3, so we know the code works fine with less than the
> max).
> Yet, I want to understand why this is urgent now.
> 
> CCing other architecture maintainers.

Tested this change with an arm64 machine + 4.18 kernel. Looks OK.
Tested-by: Jerin Jacob <jerinj at marvell.com>  

> 
> 
> --
> David Marchand


More information about the dev mailing list