RE: Updating examples which use coremask parameters

["Morten Brørup" <mb@smartsharesystems.com>]

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

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

> 
> 3. An interesting further alternative is to allow apps to take both
>   coremasks and corelists and use heuristics to determine which is
> which.
>   For example, anything starting with "0x" is a mask, anything
> containing
>   "-" or "," is a list. There would be ambiguous values such as e.g. 2,
>   which could be either, but we can always find ways to disambiguate
> these,
>   e.g. allow trailing commas in lists, so that "0x2" is the coremask,
> and "2,"
>   is the corelist. [Could be other alternatives]. This largely keeps
> backward
>   compatibility and also allows use of corelists.
> 
> 4. something else??
> 
> Thoughts and feedback, please? We'd like to upstream some fixes for the
> examples in 2024 and would rather get agreement on the approach now
> than
> head down a wrong approach. Personally, I'd rather avoid #1, and #3 is
> neat, but perhaps being overly smart/complicated?
> 
> Regards,
> /Bruce