All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: David Marchand <david.marchand@redhat.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: stable@dpdk.org, dev@dpdk.org,
	Olivier Matz <olivier.matz@6wind.com>,
	Kevin Traynor <ktraynor@redhat.com>
Subject: Re: [dpdk-stable] [PATCH v2 2/2] eal: restrict ctrl threads to startup cpu affinity
Date: Tue, 19 Feb 2019 17:03:03 +0100	[thread overview]
Message-ID: <4081676.pH4rpHE09Y@xps> (raw)
In-Reply-To: <CAJFAV8wRz=efMb7M0d0mSSiKf6cvB8UZwKz8=LuUOK4EwCxQ5A@mail.gmail.com>

19/02/2019 12:51, David Marchand:
> On Tue, Feb 19, 2019 at 12:38 PM Burakov, Anatoly <anatoly.burakov@intel.com>
> wrote:
> > On 14-Feb-19 1:30 PM, David Marchand wrote:
> > > --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> > > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> > > +Control Thread API
> > > +~~~~~~~~~~~~~~~~~~
> > > +
> > > +It is possible to create Control Threads using the public API
> > ``rte_ctrl_thread_create()``.
> > > +Those threads can be used for management/infrastructure tasks and are
> > used internally by DPDK for multi process support and interrupt handling.
> > > +
> > > +Those threads will be scheduled on cpus part of the original process
> > cpu affinity from which the dataplane and service lcores are excluded.
> > > +
> > > +For example, on a 8 cpus system, starting a dpdk application with -l
> > 2,3 (dataplane cores), then depending on the affinity configuration which
> > can be controlled with tools like taskset (Linux) or cpuset (FreeBSD),
> > > +
> > > +- with no affinity configuration, the Control Threads will end up on
> > 0-1,4-7 cpus.
> > > +- with affinity restricted to 2-4, the Control Threads will end up on
> > cpu 4.
> > > +- with affinity restricted to 2-3, the Control Threads will end up on
> > cpu 2 (master lcore, which is the default when no cpu is available).
> >
> > You're not winning anything by foregoing the 80 char limit on
> > documentation (doxygen will still generate this correctly), but you're
> > losing in readability when working in terminal. I would prefer if you
> > didn't do those long lines :)
> 
> I don't really care, I will just wait for Thomas opinion.
> 
> > Thomas, do we want checkpatch to warn about this?

http://doc.dpdk.org/guides/contributing/documentation.html#line-length

Lines should not exceed 80 chars.
There is a tradition of being very flexible in docs.
The best is to wrap at the end of a logical group of words,
like after commas or dots. So the doc updates patches are easier to read.

  reply	other threads:[~2019-02-19 16:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 16:13 [PATCH] eal: restrict ctrl threads to startup cpu affinity David Marchand
2019-02-13 20:21 ` David Marchand
2019-02-14  9:39 ` Burakov, Anatoly
2019-02-14  9:53   ` David Marchand
2019-02-14 10:04     ` Burakov, Anatoly
2019-02-14 10:16       ` David Marchand
2019-02-14 11:05 ` David Marchand
2019-02-14 13:30 ` [PATCH v2 1/2] eal: fix potential incorrect pinning for ctrl threads David Marchand
2019-02-14 13:30   ` [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 [this message]
2019-02-14 16:12   ` [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   ` [PATCH v3 " David Marchand
2019-02-19 20:41     ` [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           ` Thomas Monjalon
2019-02-20 16:01     ` [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=4081676.pH4rpHE09Y@xps \
    --to=thomas@monjalon.net \
    --cc=anatoly.burakov@intel.com \
    --cc=david.marchand@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.