DPDK patches and discussions
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>,
	"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	Adrien Mazarguil <adrien.mazarguil@6wind.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] testpmd: add nanosleep in main loop
Date: Fri, 10 Nov 2017 08:51:02 -0500	[thread overview]
Message-ID: <20171110085102.4b86397a@redhat.com> (raw)
In-Reply-To: <20171110111451.GA9164@bricha3-MOBL3.ger.corp.intel.com>

On Fri, 10 Nov 2017 11:14:51 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:

> On Fri, Nov 10, 2017 at 11:42:56AM +0100, Daniel Bristot de Oliveira wrote:
> > 
> > 
> > On 11/10/2017 11:14 AM, Ananyev, Konstantin wrote:  
> > > Agree with Adrian here - the patch doesn't fix the problem in any case,  
> > 
> > I would agree with you if it were possible to assume one can fully
> > isolate a CPU on Linux... but it is not...
> > 
> > This:
> > https://lwn.net/Articles/659490/
> > 
> > is still an open issue, and the reason why it is an open issue is the
> > kernel threads that need to run on every CPU, mainly when using the
> > PREEMPT_RT, which turns almost everything on threads.
> >   
> > > while introducing an unnecessary slowdown in testpmd iofwd mode.
> > > Please think up some other approach.  
> > 
> > The other approach is to increase the priority of all other threads that
> > run on the isolate CPU. But that is not a good idea at all, as the other
> > threads might preempt the busy-loop thread at the worst possible moment.
> > 
> > Using the knowledge of the thread about when it is the best time to give
> > a chance for other threads to run would be a smarter decision.
> >   
> I don't like having this in the main loop either, and to echo others I
> wouldn't have thought that testpmd was actually used as anything other
> than a testing app. 

That's why we're patching it. We want to be aware of the implications.
If it's not good for testpmd, it may not be good for production either.

  reply	other threads:[~2017-11-10 13:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-10  6:02 Marcelo Tosatti
2017-11-10  9:12 ` Adrien Mazarguil
2017-11-10 10:13   ` Daniel Bristot de Oliveira
2017-11-10 10:14   ` Ananyev, Konstantin
2017-11-10 10:42     ` Daniel Bristot de Oliveira
2017-11-10 11:14       ` Bruce Richardson
2017-11-10 13:51         ` Luiz Capitulino [this message]
2017-11-11  3:59           ` Marcelo Tosatti
2017-11-11  4:01             ` Marcelo Tosatti
2017-11-11  3:54         ` Marcelo Tosatti
2017-11-11  3:49     ` Marcelo Tosatti
2017-11-12 23:14       ` Ananyev, Konstantin
2017-11-13 18:01         ` Marcelo Tosatti
2017-11-11  3:45   ` Marcelo Tosatti

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=20171110085102.4b86397a@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=bristot@redhat.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=mtosatti@redhat.com \
    /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).