Re: Updating examples which use coremask parameters

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Nov 02, 2023 at 06:05:59PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Thursday, 2 November 2023 15.57
> > 
> > Hi all,
> > 
> > looking to start a discussion and get some input here.
> > 
> > There are a number of our examples in DPDK which still track core usage
> > via
> > a 64-bit bitmask, and, as such, cannot run on cores between 64 and
> > RTE_MAX_LCORE. Two examples I have recently come across with this issue
> > are
> > "eventdev_pipeline" and "qos_sched", but I am sure there are others.
> > The
> > former is a good example (or bad example depending on your viewpoint)
> > of
> > this as it takes multiple coremask parameters - for RX cores, for TX
> > cores,
> > for worker cores and optionally for scheduler cores.
> > 
> > Now, the simple solution to this is to just expand the 64-bit bitmask
> > to
> > 128 bit or more, but I think that is just making things harder for the
> > user, since dealing with long bitmasks is very awkward and unwieldy.
> > Better
> > instead to convert all examples using coremasks to using core lists
> > instead.
> > 
> > First step should be to take our EAL corelist processing code and
> > refactor
> > it into a function that can be made public, so that it can be used by
> > all
> > apps for parsing core lists. Simple enough!
> 
> If not already there, consider adding support for open-ended lists, e.g. "2-" means from 2 to the rest of the available cores.
> 

Interesting proposal. It's not there yet, we'll have to look into it.

> > 
> > The next part I'm looking for input on is - how do we switch the apps
> > from
> > coremasks to core lists? Some options:
> > 
> > 1. Add in new commandline parameters for each app to work with core
> > lists.
> >   This is what we did in the past with EAL, by adding -l as a
> > replacement
> >   for -c. The advantage is that we maintain backward compatibility, but
> > the
> >   downside is that it becomes hard to find new suitable letter options
> > for
> >   the core lists. Taking eventdev_pipeline again, we would need "new"
> >   options for "-r", "-t", "-w" and "-s" parameters. Using the
> > capitalized
> >   versions of these would be a simple alternative, but "-W" is already
> > used
> >   as an app parameter so we can't do that.
> > 
> > 2. Just break backward compatibility and switch the apps to taking
> >   core lists instead of masks. Advantage is that it gives us the
> > cleanest
> >   solution, but the downside is that and testing done using these
> > examples,
> >   or any users who may have run them in the past, get different
> > behaviour.
> 
> I'm in favor of 2.
> 
> Coremasks are obsolete. Examples should not use them as parameters or internally.
> 
> We could emit an informational log message if a given corelist parameter could be a coremask (i.e. if it also conforms to coremask formatting).
> When enough time has passed since introducing this change, this check (and associated log message) could be removed.
> 

Thanks for the feedback.

/Bruce