Re: Updating examples which use coremask parameters

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

On Fri, Nov 03, 2023 at 10:11:08AM +0000, Konstantin Ananyev wrote:
> 
> > 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!
> > 
> > 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.
> 
> 
> As it is for examples, I also don't see any issue with converting to core-list.
> Said that, I suppose we still want to keep EAL '-c' (coremask) parameter, right?
> If so, then it might be plausible to consider making the code that handles it
> to work with really-long ones (up to 1K, or whatever is our current CPU_SET limit).

I believe the EAL coremask parsing already supports >64 lcores, and works
with arbitrary lengths up to RTE_MAX_LCORE, so I think we are ok here. It
parses the coremask char-by-char (backwards) as a string, rather than
trying to convert it using atoi-type functions[1].

/Bruce

[1] http://git.dpdk.org/dpdk/tree/lib/eal/common/eal_common_options.c#n777