> 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
