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 73FF943270; Thu, 2 Nov 2023 17:28:50 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6124A41143; Thu, 2 Nov 2023 17:28:50 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 9A04340E13; Thu, 2 Nov 2023 17:28:48 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id F3E3432008C0; Thu, 2 Nov 2023 12:28:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 02 Nov 2023 12:28:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1698942525; x=1699028925; bh=0jAdeQHKGIeGo0OE5o6Q/ao8mQQPSCe3aMo Squ11ZN4=; b=WhRLc2A1vUGrJwvmgmgKUSVHQ3GoFUViZpbi9EfwVIjEf6skAYJ dWKPNC089A3iBdepMaZmoze0Wo7ge23TyoD/EM6XMRovepHsrponLcQVj7qVWjKQ WQ21pM3zbUHIbCPaWvOATKhjntcyLQtdxuFYbWSOOGi87gxr45kwUKSVt6tKPn3w Lgi+8chbbWSDgPikDvvqJYgQwBCSgYnYel9KeaN/1FWVtRmF3r0McrIjQTeiGqCz +nkSXDw/ddnDmwVH/V74sBcFXdse/gksoNm+xMjeya9S9o/F1/PyW5nu1B2rJl7j ODVxw9NvGn/5anB+KQUXd5SPTYdefayfZdg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1698942525; x=1699028925; bh=0jAdeQHKGIeGo0OE5o6Q/ao8mQQPSCe3aMo Squ11ZN4=; b=jeP7kfaNa7JAuM86ZNlGRuu3a6dZVxMRMyPOp9fEBznvgwcVTzZ pm4hnNQ96isVQfPcaT59bk1iq+AnOoug82HjhBY7b54S6DpFh70riA84rVBOY2sZ 1wBbO4Fy/qqYb9PVq11AUofUxRneoRsvrPgD8WzURNYtVq0SCNANDNLOcCKax5G6 r8JUakR83kRH4BL64T3nRKbbbXAVD7g3aei/cC6W6zka+pfskSqginmXDi2AyEEk 21zu0TAHQH4MvRMezeH4ILikxb0iuSJcqJ/D7y7wRkt2XrmEMeAktoaTb8MB3xQt 17AkoTCm6Ub2SDbRmDvvdQqniHQfeZ+uysw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtiedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Nov 2023 12:28:43 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org, techboard@dpdk.org, Euan Bourke Subject: Re: Updating examples which use coremask parameters Date: Thu, 02 Nov 2023 17:28:42 +0100 Message-ID: <4175883.1IzOArtZ34@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 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