Re: [dpdk-dev] [PATCH v2 3/4] test: change memory barrier variables to uint64_t

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> -----Original Message-----
> From: David Christensen [mailto:drc@linux.vnet.ibm.com]
> Sent: Tuesday, May 7, 2019 6:38 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 3/4] test: change memory barrier variables to uint64_t
> 
> >> @@ -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.

If you feel that it might be useful, then it is ok by me.
Konstantin

> 
> >> -		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