From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id A48A91B206 for ; Sat, 11 Nov 2017 17:14:54 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1748C25C21; Sat, 11 Nov 2017 16:14:54 +0000 (UTC) Received: from amt.cnet (ovpn-112-2.gru2.redhat.com [10.97.112.2]) by smtp.corp.redhat.com (Postfix) with ESMTP id E33035D978; Sat, 11 Nov 2017 16:14:47 +0000 (UTC) Received: from amt.cnet (localhost [127.0.0.1]) by amt.cnet (Postfix) with ESMTP id 1172D1050DB; Sat, 11 Nov 2017 01:59:22 -0200 (BRST) Received: (from marcelo@localhost) by amt.cnet (8.14.7/8.14.7/Submit) id vAB3xLQt024347; Sat, 11 Nov 2017 01:59:21 -0200 Date: Sat, 11 Nov 2017 01:59:21 -0200 From: Marcelo Tosatti To: Luiz Capitulino Cc: Bruce Richardson , Daniel Bristot de Oliveira , "Ananyev, Konstantin" , Adrien Mazarguil , "dev@dpdk.org" Message-ID: <20171111035921.GD23577@amt.cnet> References: <20171110060210.GA23340@amt.cnet> <20171110091219.GE24849@6wind.com> <2601191342CEEE43887BDE71AB9772585FABBC64@irsmsx105.ger.corp.intel.com> <20171110111451.GA9164@bricha3-MOBL3.ger.corp.intel.com> <20171110085102.4b86397a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171110085102.4b86397a@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Sat, 11 Nov 2017 16:14:54 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH] testpmd: add nanosleep in main loop X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 16:14:55 -0000 On Fri, Nov 10, 2017 at 08:51:02AM -0500, Luiz Capitulino wrote: > On Fri, 10 Nov 2017 11:14:51 +0000 > Bruce Richardson 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. The arguments raised so far against the patch have been: 1) Performance is reduced. Reply: * Of course performance is reduced, but any solution will also reduce performance similary. * Performance is reduced but within the acceptable limits set by NFV standards. So the performance reduction argument is kind of not an issue (in my POV). 2) Testpmd is a test application. Well, if one would like to avoid XFS corruption or other similar results caused by the not possibility of running poll mode testpmd (while testing) then he should enable the options (which are disabled by default). Moreover, testpmd is an example application used by production developers, so it should be integrated to testpmd. Does anyone have arguments against the reasoning above ?