From: Gagandeep Singh <G.Singh@nxp.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: David Marchand <david.marchand@redhat.com>, dev <dev@dpdk.org>,
"Burakov, Anatoly" <anatoly.burakov@intel.com>,
Olivier Matz <olivier.matz@6wind.com>,
Andrew Rybchenko <arybchenko@solarflare.com>,
Nipun Gupta <nipun.gupta@nxp.com>
Subject: Re: [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4
Date: Wed, 7 Aug 2019 12:53:46 +0000 [thread overview]
Message-ID: <AM0PR04MB63566933179DA13F296B21D1E1D40@AM0PR04MB6356.eurprd04.prod.outlook.com> (raw)
Hi Thomas,
> 07/08/2019 14:00, David Marchand:
> > On Wed, Aug 7, 2019 at 12:26 PM Gagandeep Singh <g.singh@nxp.com>
> wrote:
> > >
> > > 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.
It is critical for stacks like VPP which uses by default in-memory.
There stack would be broken on kernel 5.2 and above.
I will change the description to make it clear.
> Should we Cc stable@dpdk.org for backport?
yes
> Should it be merged at the last minute in 19.08?
If this is the only change, that we need to do (i.e. no dynamic allocation), then yes it can go.
next reply other threads:[~2019-08-07 12:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 12:53 Gagandeep Singh [this message]
2019-08-07 14:09 ` [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4 Honnappa Nagarahalli
-- strict thread matches above, loose matches on Subject: below --
2019-08-08 9:00 Gagandeep Singh
2019-08-08 9:22 ` David Marchand
2019-08-07 12:47 Gagandeep Singh
2019-08-07 10:12 Gagandeep Singh
2019-08-07 12:00 ` David Marchand
2019-08-07 12:07 ` Thomas Monjalon
2019-08-07 13:28 ` Hemant Agrawal
2019-08-08 7:31 ` Thomas Monjalon
2019-08-12 9:43 ` Burakov, Anatoly
2019-08-12 9:49 ` David Marchand
2019-08-12 10:01 ` Thomas Monjalon
2019-08-12 10:38 ` Burakov, Anatoly
2019-08-08 7:33 ` David Marchand
2019-08-08 10:37 ` Hemant Agrawal
2019-08-08 12:29 ` Steve Capper
2019-08-08 12:39 ` David Marchand
2019-08-12 9:42 ` Burakov, Anatoly
2019-08-07 15:27 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM0PR04MB63566933179DA13F296B21D1E1D40@AM0PR04MB6356.eurprd04.prod.outlook.com \
--to=g.singh@nxp.com \
--cc=anatoly.burakov@intel.com \
--cc=arybchenko@solarflare.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=nipun.gupta@nxp.com \
--cc=olivier.matz@6wind.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).