DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: <dev@dpdk.org>, <techboard@dpdk.org>
Cc: Euan Bourke <euan.bourke@intel.com>
Subject: Updating examples which use coremask parameters
Date: Thu, 2 Nov 2023 14:56:45 +0000	[thread overview]
Message-ID: <ZUO4rYvj/giJZq4d@bricha3-MOBL.ger.corp.intel.com> (raw)

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!

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.

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.

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

             reply	other threads:[~2023-11-02 14:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02 14:56 Bruce Richardson [this message]
2023-11-02 16:28 ` Thomas Monjalon
2023-11-02 16:58   ` Bruce Richardson
2023-11-06 19:19     ` Stephen Hemminger
2023-11-02 17:05 ` Morten Brørup
2023-11-02 17:15   ` Bruce Richardson
2023-11-03 10:11 ` Konstantin Ananyev
2023-11-03 10:16   ` Bruce Richardson
2023-11-06 21:37     ` Konstantin Ananyev
2023-11-07  9:50       ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZUO4rYvj/giJZq4d@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=euan.bourke@intel.com \
    --cc=techboard@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).