DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"techboard@dpdk.org" <techboard@dpdk.org>,
	 Euan Bourke <euan.bourke@intel.com>
Subject: Re: Updating examples which use coremask parameters
Date: Tue, 7 Nov 2023 09:50:25 +0000	[thread overview]
Message-ID: <ZUoIYYWp/4kQgLB1@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <8d2ceeb3b16b4467ac98942d8067d736@huawei.com>

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.

      reply	other threads:[~2023-11-07  9:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02 14:56 Bruce Richardson
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 [this message]

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=ZUoIYYWp/4kQgLB1@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=euan.bourke@intel.com \
    --cc=konstantin.ananyev@huawei.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).