From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <marc.sune@bisdn.de>
Received: from mx.bisdn.de (mx.bisdn.de [185.27.182.31])
 by dpdk.org (Postfix) with ESMTP id 19D4068AF
 for <dev@dpdk.org>; Fri, 14 Nov 2014 10:22:46 +0100 (CET)
Received: from [172.16.250.161] (unknown [172.16.250.161])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx.bisdn.de (Postfix) with ESMTPSA id 1C141A3066;
 Fri, 14 Nov 2014 10:32:48 +0100 (CET)
Message-ID: <5465CC40.2070403@bisdn.de>
Date: Fri, 14 Nov 2014 10:32:48 +0100
From: Marc Sune <marc.sune@bisdn.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20131103 Icedove/17.0.10
MIME-Version: 1.0
To: Morten Jagd Christensen <mjc@xenanetworks.com>, 
 "<dev@dpdk.org>" <dev@dpdk.org>
References: <002001cffe5d$2ecf1290$8c6d37b0$@xenanetworks.com>
 <C6ECDF3AB251BE4894318F4E4512369780C084E2@IRSMSX109.ger.corp.intel.com>
 <54638167.9030604@bisdn.de>
 <038401cfffe9$dff1c3a0$9fd54ae0$@xenanetworks.com>
In-Reply-To: <038401cfffe9$dff1c3a0$9fd54ae0$@xenanetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] Valgrind and DPDK - RDRAND + RTE_MACHINE obstacle
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 09:22:46 -0000

On 14/11/14 10:03, Morten Jagd Christensen wrote:
> Hi Marc,
>
> It turns out that I could successively comment out the setting of cpu flags
> in mk/rte.cpuflags,
> rebuild dpdk and my application, and then run valgrid until no further error
> messages occured.
>
> But it turns out to be too slow for practical purposes :-(

(Please, do not drop the list, it might be helpful to others)

Ok, I am not sure if this can cause you any problem. Perhaps someone in 
the community can advise you here.

valgrind should only be used to do functional testing, not for 
performance. But for doing so I strongly suggest to do this:

> [snip]
> One recommendation: once it is working, unless you have a very 
> powerful machine (which my VM isn't) I recommend to add some usleeps 
> in the main I/O loops when running valgrind, otherwise due to the 
> heavyweight emulation valgrind does it slows down application 
> execution considerably. Let's see if it helps. Marc 

Best
Marc