Re: more than 64 lcores not properly supported

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 23 Feb 2022 14:49:12 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> 23/02/2022 12:20, Ferruh Yigit:
> > On 2/23/2022 10:42 AM, Morten Brørup wrote:  
> > > +Thomas, you may be interested in this discussion about applications using an uint64_t bit mask to identify active lcores.
> > >   
> > >> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
> > >> Sent: Wednesday, 23 February 2022 11.03
> > >>
> > >> On 2/23/2022 7:17 AM, Morten Brørup wrote:  
> > >>>> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > >>>> Sent: Tuesday, 22 February 2022 17.03  
> > > 
> > > [...]
> > >   
> > >>>>
> > >>>> DPDK now supports > 64 lcores. So all code using/assuming a 64 bit  
> > >> mask  
> > >>>> is broken.
> > >>>>  
> > >>>
> > >>> Good point. Is there a TODO-list where such a general review request  
> > >> can be filed, or should we just file it as a system-wide bug in
> > >> Bugzilla?  
> > >>>
> > >>> Nonetheless, I think this one-line fix should be accepted as a short  
> > >> term solution.  
> > >>>  
> > >>
> > >> Hi Morten,
> > >>
> > >> I suspect there can be more places that testpmd assumes
> > >> max core number is 64, someone needs to spend time to
> > >> analyze and fix it.  
> > > 
> > > My point exactly. Someone needs to spend time to analyze all DPDK libraries and applications, and fix it where appropriate. Where do we register this required effort, so it can be picked up by someone?
> > >   
> > 
> > testpmd is an application and it has its own restrictions,
> > I *assumed* libraries are safe and restriction is only in
> > testpmd, but may be better to verify this as well.
> >   
> > > Also, it should probably be mentioned as a known bug in the 22.03 release notes.  
> 
> There are known bugs and things to verify.
> Known bugs should be in bugzilla + release notes.
> Verification tasks are difficult to track because there is no point
> where we can be sure that things are fully verified.
> Instead I think such kind of verification should be managed
> as permanent tasks. Do you have a tool or process in mind?
> 
> 

Agree take the fix for now.
Since many places use a mask of cpus and/or ports. It would be good
to have common code for handling this.