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 3E48F432BC; Mon, 6 Nov 2023 20:19:48 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B8FAE40689; Mon, 6 Nov 2023 20:19:47 +0100 (CET) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id 199AF402B1 for ; Mon, 6 Nov 2023 20:19:46 +0100 (CET) Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-28041176e77so3638761a91.0 for ; Mon, 06 Nov 2023 11:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1699298386; x=1699903186; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=4rJ6hnnbi6hPczkq88JtEGlPYEuRIhijP4dBPAiWjM0=; b=aMh4ob49YSh+S1RS3N7yLpWWqeifAxvaunMeC+WN4Rt//ZrCQ37fg+XInse/gpOCOv CSZ5UJyjD+GMGWSDofpsa0wZgC0NYgLwC7Bpq8x5vKmoyI2RzmcGYjEVTdS5azyGyZil xmu9h+hKAGVmxU8RAQXtJMYHTMS/w56Ll8HdbzFl5J9ThyMndT5j3rQ2CNjXalfcs/fU LdFAHYUMW0/XOl6/Dzc7QzJLnele+5HwbItl6PlnLIgCyZAIa8ubTLHaKg5ywR2lcjDL LcdB16wiHILabal+40GAOkpKoM6ONlPT+1Cma1fP2gIvrMpIMm7HpBC/3GTMpPr6LjN1 8WDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699298386; x=1699903186; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4rJ6hnnbi6hPczkq88JtEGlPYEuRIhijP4dBPAiWjM0=; b=bvWWsE/cdNI0XNeKkEiB/LuPTGGqwYrlTXu8ZM+NbpFIGoCOqdYXzDVClW9h3H71HX /EzSYSfvntiIoK326fEdtC4rO0dPtvp1g+Pg4mOflaGmDO77zlwcAOfYRoEULvq2cmCi nx6kx0eitGk7ryPcrHGNL4tRMmWswH1Tia1mcOv5qmX7/TU1nn4Bq0SN8DlkWiV9Z7V9 FmItzrgpHHMWCsmfDjChdYvb84AfhRlEiLaWUhgdoyXqoQP5ieT+9omI6qJaAsCp6GCm awZQbYw/OpBD2SjK4eRcLxGXir8+uLeM3gs1Mm44w7ZsVCBokE3+FmMiLZpniNrH69wQ lWEQ== X-Gm-Message-State: AOJu0Yxok8/Xf9kNspt3GHxWX8fSu8Twkmm95+QksqujhB6yuxjqsu+g vwBzv+c02GD7UkyIX5xmXCdmjA== X-Google-Smtp-Source: AGHT+IHmHR0oQQsXG7OY1jHDkSfGB3gQD8lajqvOdfVukzdUGxr1QLubcTKI7OMUAcnl+T4EWhLfFQ== X-Received: by 2002:a17:90a:8c0e:b0:27d:1ea0:bc84 with SMTP id a14-20020a17090a8c0e00b0027d1ea0bc84mr23379455pjo.34.1699298386029; Mon, 06 Nov 2023 11:19:46 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id nn17-20020a17090b38d100b0027909a8994fsm5871912pjb.13.2023.11.06.11.19.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 11:19:45 -0800 (PST) Date: Mon, 6 Nov 2023 11:19:43 -0800 From: Stephen Hemminger To: Bruce Richardson Cc: Thomas Monjalon , , , Euan Bourke Subject: Re: Updating examples which use coremask parameters Message-ID: <20231106111943.4ccca8ed@hermes.local> In-Reply-To: References: <4175883.1IzOArtZ34@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Thu, 2 Nov 2023 16:58:52 +0000 Bruce Richardson wrote: > On Thu, Nov 02, 2023 at 05:28:42PM +0100, Thomas Monjalon wrote: > > 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. > > > > Funnily enough, separate to this I had already been working on an > "rte_args" library to have some functions for working on argc/argv > parameters. I'm planning on pushing out an RFC for 24.03 fairly shortly. > > However, pulling in functions for arg parsing is a different set of > functionality to what I had in mind, so we may yet get two libraries out of > this. [Merging may be tricky due to issues around circular dependencies > with EAL. My arg management library is designed to "sit on top of" EAL, > while any lib offering e.g. coremask, corelist parsing functions would need > to "sit beneath" EAL, so EAL can re-use it's functions]. > > Let's postpone the details of both these to when we get some RFCs out > though. > > > > > 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. > > > > Glad to hear it. Makes life simpler. > > > > 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. > > > Yep. If we start offering a library of arg-parsing functions, one of those > could be a function using heuristics to identify core-mask, core-list or > ambiguous values. Then each app can decide what to do in the latter case. > Since we don't care about backward compatibility, the examples can just parse > ambiguous values as core-list. User could then still use coremasks by > prefixing them with "0x". Noticed that lib/graph is using 64 bit coremask internally. Wonder if others have the same issue. Would be good if DPDK had a library to handle cpusets better, something like the Linux kernel cpuset which uses comma separated list of cpu masks.