On Mon, Nov 06, 2023 at 09:37:31PM +0000, Konstantin Ananyev wrote: > > > > > > > > > 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). > > > > I believe the EAL coremask parsing already supports >64 lcores, and works > > with arbitrary lengths up to RTE_MAX_LCORE, so I think we are ok here. It > > parses the coremask char-by-char (backwards) as a string, rather than > > trying to convert it using atoi-type functions[1]. > > Great, thanks for clarifying. > I suppose next question here - would it make sense to convert that code into > some public API, > so we can have one function for core-mask parsing that will be used for both > EAL and user apps? >
Yes, that is the intention.
