[dpdk-dev] [PATCH v1 1/6] build: increase default of max lcores to 512

[David Marchand]

On Tue, Sep 14, 2021 at 11:34 AM David Hunt <david.hunt at intel.com> wrote:
>
>
> 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.richardson at 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.richardson at 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.hunt at 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

Let's avoid typo in the error message you'll add :-).


> 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).”

If you could directly provide the right --lcores syntax based on what
user provided with -c or -l, it would be even better.
This should be not that difficult.


>
> I’ll replace the first patch in the set with a patch that adds the
> additional information in the error message.



-- 
David Marchand