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

[David Marchand <david.marchand@redhat.com>]

On Fri, Sep 10, 2021 at 9:54 AM Bruce Richardson
<bruce.richardson@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@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@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.


-- 
David Marchand