DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Christensen <drc@linux.vnet.ibm.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 3/4] test: change memory barrier variables to uint64_t
Date: Tue, 7 May 2019 10:37:49 -0700	[thread overview]
Message-ID: <0d1cc529-f44c-08dc-6bce-d52643fc8e8a@linux.vnet.ibm.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772580148AA2191@irsmsx105.ger.corp.intel.com>

>> @@ -65,8 +65,8 @@ struct plock_test {
>>    */
>>   struct lcore_plock_test {
>>   	struct plock_test *pt[2]; /* shared, lock-protected data */
>> -	uint32_t sum[2];          /* local copy of the shared data */
>> -	uint32_t iter;            /* number of iterations to perfom */
>> +	uint64_t sum[2];          /* local copy of the shared data */
>> +	uint64_t iter;            /* number of iterations to perfom */
>>   	uint32_t lc;              /* given lcore id */
>>   };
> 
> Not sure why you think this is needed - right now
> both iter and sum wouldn't be bigger than 32bit
> (max value that sum can reach: 2^27).
> 

I view test_barrier and other tools in the test directory as functional 
test tools for developers.  My understanding is that they are not 
typically run as part of DTS or any other validation process (please let 
me know if that is incorrect).  As a result, a developer that is testing 
this functionality might have a valid reason to alter the value of 
ITER_MAX for a specific functional test.

While validating the changes in patch 4 of the series I needed to run 
more that 2^27 iterations.  I encountered situations where some runs of 
my test code would fail and other runs would pass when using the default 
ITER_MAX value.  As a result, I needed to extend the number of 
iterations tested to gain confidence in the final fix for Power systems. 
At the end, I was running 64 billion iterations (MAX_ITER = 
0xF_0000_0000) across 64 Power 9 lcores which takes ~16 hours.

I felt the patch to extend these values to 64 bit might benefit other 
developers in the future. And since the cost is low (this is not EAL 
library code pulled into every user application) there's no harm in 
making the change.

>> -		printf("%s: sum[%u]=%u, pt[%u].val=%u, pt[%u].iter=%u;\n",
>> +		printf("%s: sum[%u]=%lu, pt[%u].val=%lu, pt[%u].iter=%lu;\n",
> 
> Here and in other places, you need to use PRIu64 for 64 bit values.

Ok. I'll resubmit if there are no objections to the rationale behind the 
change.

Dave

  parent reply	other threads:[~2019-05-07 17:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06 19:23 David Christensen
2019-05-06 19:23 ` David Christensen
2019-05-07 10:39 ` Ananyev, Konstantin
2019-05-07 10:39   ` Ananyev, Konstantin
2019-05-07 17:37   ` David Christensen [this message]
2019-05-07 17:37     ` David Christensen
2019-05-07 23:15     ` Ananyev, Konstantin
2019-05-07 23:15       ` Ananyev, Konstantin

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=0d1cc529-f44c-08dc-6bce-d52643fc8e8a@linux.vnet.ibm.com \
    --to=drc@linux.vnet.ibm.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.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).