RE: Updating examples which use coremask parameters

[Konstantin Ananyev <konstantin.ananyev@huawei.com>]

> 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).
Then if we'll have such function as a public one, users can still probably continue
to use core-mask/core-list at their best convenience.  

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