On Thu, Nov 02, 2023 at 06:05:59PM +0100, Morten Brørup wrote: > > 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. >
Interesting proposal. It's not there yet, we'll have to look into it. > > > > 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. > Thanks for the feedback. /Bruce
