> From: Bruce Richardson [mailto:bruce.richard...@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
