From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0946E43270; Thu, 2 Nov 2023 18:06:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EF215427E7; Thu, 2 Nov 2023 18:06:01 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id CAD1C427E7; Thu, 2 Nov 2023 18:06:00 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id A9718208A2; Thu, 2 Nov 2023 18:06:00 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Updating examples which use coremask parameters X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 2 Nov 2023 18:05:59 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EFCC@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating examples which use coremask parameters Thread-Index: AdoNnOoXQ29LizTASPuL4vODy3u09gAEHl7Q References: From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" , , Cc: "Euan Bourke" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Thursday, 2 November 2023 15.57 >=20 > Hi all, >=20 > looking to start a discussion and get some input here. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > The next part I'm looking for input on is - how do we switch the apps > from > coremasks to core lists? Some options: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 4. something else?? >=20 > 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? >=20 > Regards, > /Bruce