Hi Stephen,
On Tue, 9 Jun 2020 12:43:57 -0700, Stephen Hemminger
<step...@networkplumber.org> wrote:
> On Tue, 9 Jun 2020 15:07:19 -0400
> Vivien Didelot <vivien.dide...@gmail.com> wrote:
>
> >
> > +#define NSEC_PER_SEC 1000000000L
> > +
> > static inline void
> > calculate_timestamp(struct timeval *ts) {
> > uint64_t cycles;
> > @@ -294,8 +296,14 @@ calculate_timestamp(struct timeval *ts) {
> >
> > cycles = rte_get_timer_cycles() - start_cycles;
> > cur_time.tv_sec = cycles / hz;
> > - cur_time.tv_usec = (cycles % hz) * 1e6 / hz;
> > - timeradd(&start_time, &cur_time, ts);
> > + cur_time.tv_usec = (cycles % hz) * NSEC_PER_SEC / hz;
> > +
> > + ts->tv_sec = start_time.tv_sec + cur_time.tv_sec;
> > + ts->tv_usec = start_time.tv_usec + cur_time.tv_usec;
> > + if (ts->tv_usec >= NSEC_PER_SEC) {
> > + ts->tv_usec -= NSEC_PER_SEC;
> > + ts->tv_sec += 1;
> > + }
> > }
> >
>
> You may want to pre-compute the reciprocal here to save the expensive
> cost of divide in the fast path. See rte_reciprocal.
Please note that I did not change the calculation logic that was previously
used here. Thus pre-computing the reciprocal here to save the expensive cost
of divide in the fast path seems out of the scope of this patch to me.
Can we keep this for a future patch maybe?
Thanks,
Vivien
