> -----Original Message-----
> From: David Christensen [mailto:d...@linux.vnet.ibm.com]
> Sent: Tuesday, May 7, 2019 6:38 PM
> To: Ananyev, Konstantin <konstantin.anan...@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
