From: David Marchand <david.marchand@redhat.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, Olivier Matz <olivier.matz@6wind.com>,
Kevin Traynor <ktraynor@redhat.com>,
dpdk stable <stable@dpdk.org>
Subject: Re: [dpdk-stable] [PATCH] eal: restrict ctrl threads to startup cpu affinity
Date: Thu, 14 Feb 2019 10:53:11 +0100 [thread overview]
Message-ID: <CAJFAV8zyeA16eY+mgq3_V2szUOV38=i0G_2uMjRDrUm-+fJq_w@mail.gmail.com> (raw)
In-Reply-To: <e2c73723-8b2c-a12d-96cc-a141ef001c75@intel.com>
On Thu, Feb 14, 2019 at 10:39 AM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> On 13-Feb-19 4:13 PM, David Marchand wrote:
> > Spawning the ctrl threads on anything that is not part of the eal
> > coremask is not that polite to the rest of the system.
> >
> > Rather than introduce yet another eal options for this, let's take
> > the startup cpu affinity as a reference and remove the eal coremask
> > from it.
> > If no cpu is left, then we default to the master core.
> >
> > The cpuset is computed once at init before the original cpu affinity.
> >
> > Fixes: d651ee4919cd ("eal: set affinity for control threads")
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
>
> Hi David,
>
> Maybe i didn't have enough coffee today and i'm missing something here,
> but how is this different? Removing the coremask cores from the cpuset
> will effectively "spawn the ctrl threads on anything that is not part of
> the EAL coremask" (which is "not that polite to the rest of the
> system"), unless the application was run with taskset.
>
> Is "taskset" the key point here? I.e. by default, we're still "not
> polite", unless the user asks nicely? :)
>
Eheh, sorry, yes.
A bit more context then, if you want to clearly pin cpu resources for the
processes on your system (let's say having virtual machines and a popular
vswitch), I can only think of two solutions.
Either you have something to configure your processes to have them call
sched_setaffinity/pthread_set_affinity_np, or you use taskset to get them
"jailed" without them caring.
Before the incriminated commit, we were keeping all threads on the coremask
that had been passed, but as Olivier said, we would end up with ctrl
threads spanwed on core running dataplane threads as well.
Now, the ctrl threads can be spawned anywhere on all & ~coremask, with no
way to configure this.
I considered adding a new eal option, but I think relying on the current
cpu affinity is a better default behavior and I can't see drawbacks at the
moment.
--
David Marchand
next prev parent reply other threads:[~2019-02-14 9:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 16:13 David Marchand
2019-02-13 20:21 ` [dpdk-stable] [dpdk-dev] " David Marchand
2019-02-14 9:39 ` [dpdk-stable] " Burakov, Anatoly
2019-02-14 9:53 ` David Marchand [this message]
2019-02-14 10:04 ` Burakov, Anatoly
2019-02-14 10:16 ` David Marchand
2019-02-14 11:05 ` [dpdk-stable] [dpdk-dev] " David Marchand
2019-02-14 13:30 ` [dpdk-stable] [PATCH v2 1/2] eal: fix potential incorrect pinning for ctrl threads David Marchand
2019-02-14 13:30 ` [dpdk-stable] [PATCH v2 2/2] eal: restrict ctrl threads to startup cpu affinity David Marchand
2019-02-19 11:38 ` Burakov, Anatoly
2019-02-19 11:51 ` David Marchand
2019-02-19 16:03 ` Thomas Monjalon
2019-02-14 16:12 ` [dpdk-stable] [PATCH v2 1/2] eal: fix potential incorrect pinning for ctrl threads Burakov, Anatoly
2019-02-14 17:45 ` David Marchand
2019-02-19 20:41 ` [dpdk-stable] [PATCH v3 " David Marchand
2019-02-19 20:41 ` [dpdk-stable] [PATCH v3 2/2] eal: restrict ctrl threads to startup cpu affinity David Marchand
2019-02-20 16:01 ` Burakov, Anatoly
2019-02-25 8:33 ` Olivier Matz
2019-03-07 18:23 ` [dpdk-stable] [dpdk-dev] " Thomas Monjalon
2019-02-20 16:01 ` [dpdk-stable] [PATCH v3 1/2] eal: fix potential incorrect pinning for ctrl threads Burakov, Anatoly
2019-02-25 8:33 ` Olivier Matz
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='CAJFAV8zyeA16eY+mgq3_V2szUOV38=i0G_2uMjRDrUm-+fJq_w@mail.gmail.com' \
--to=david.marchand@redhat.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=ktraynor@redhat.com \
--cc=olivier.matz@6wind.com \
--cc=stable@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).