02/11/2023 15:56, Bruce Richardson: > 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!
OK to add some command line parsing helpers. It should probably be the start of a new library for command line. > 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. We don't need to offer backward compatibility in examples. So this option is acceptable. > 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. The option 3 can be interesting as well. > 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
