On 10/9/2021 9:24 AM, Thomas Monjalon wrote:
10/09/2021 10:06, David Marchand:
On Fri, Sep 10, 2021 at 9:54 AM Bruce Richardson
<bruce.richard...@intel.com> wrote:
On Fri, Sep 10, 2021 at 08:51:04AM +0200, David Marchand wrote:
On Thu, Sep 9, 2021 at 4:38 PM Bruce Richardson
<bruce.richard...@intel.com> wrote:
On Thu, Sep 09, 2021 at 02:45:06PM +0100, David Hunt wrote:
Modern processors are coming with an ever increasing number of cores,
and 128 does not seem like a sensible max limit any more, especially
when you consider multi-socket systems with Hyper-Threading enabled.
This patch increases max_lcores default from 128 to 512.
Signed-off-by: David Hunt <david.h...@intel.com>
Why should we need this?
--lcores makes it possible to pin 128 lcores to any physical core on
your system.
And for applications that have their own thread management, they can
pin thread, then use rte_thread_register.
Do you have applications that require more than 128 lcores?
The trouble is that using the --lcores syntax for mapping high core numbers
to low lcore ids is much more awkward to use. Every case of DPDK use I've
seen uses -c with a coremask, or -l with just giving a few core numbers on
it. This simple scheme won't work with core numbers greater than 128, and
there are already systems available with more than that number of cores.
Apart from the memory footprint issues - which this patch is already making
a good start in addressing, why would we not increase the default
max_lcores to that seen on real systems?
The memory footprint is a major issue to me, and reserving all those
lcores won't be needed in any system.
We will also have to decide on a "640k ought to be enough" value to
avoid ABI issue with the next processor that comes out and has more
than 512 cores.
Could we wire the -c / -l options to --lcores behavior ?
It breaks the 1:1 lcore/physical core assumption, but it solves your
usability issue.
Why would we change existing options while we already have an option
(--lcores) which solves the issue above?
I think the only issue is to educate users.
Is there something to improve in the documentation?
Hi all,
I agree that it’s a good idea to switch to using the “--lcrores” option
for cores above the default, that’s already future proofed.
However, I’m still a little concerned about usability, if our users are
accustomed to the “-c” and “-l” options, I suggest that we add a warning
to suggest using the “--lcores” option if any of the cores provided on
the command line are above RTE_MAX_LCORE. That would help them with the
solution to using physical cores above 128 (or whatever the compiled
default is).
Example:
“ERROR: logical core 212 is above the maximum lcore number permitted.
Please use the --lcores option to map lcores onto physical cores, e.g.
--lcores="(0-3)@(212-215).”
I’ll replace the first patch in the set with a patch that adds the
additional information in the error message.
Thanks,
Dave.
