Re: [PATCH 2/2] mlx5: fix 64-bit division on times

[Arnd Bergmann]

On Friday, June 17, 2016 6:09:00 PM CEST Saeed Mahameed wrote:
> On Wed, Jun 15, 2016 at 6:27 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > The mlx5 driver fails to build on 32-bit architectures after some
> > references to 64-bit divisions got added:
> >
> > drivers/net/built-in.o: In function `mlx5e_rx_am':
> > :(.text+0xf88ac): undefined reference to `__aeabi_ldivmod'
> >
> > The driver even performs three division here, and it uses the
> > obsolete 'struct timespec' that we want to get rid of.
> >
> > Using ktime_t and ktime_us_delta() replaces one of the divisions
> > and is mildly more efficient, aside from working across 'settimeofday'
> > calls and being the right type for the y2038 conversion.
> >
> > Using a u32 instead of s64 to store the number of microseconds
> > limits the maximum time to about 71 minutes, but if we exceed that
> > time, we probably don't care about the result any more for the
> > purpose of rx coalescing.
> >
> > For the number of packets, we are taking the difference between
> > two 'unsigned int', so the result won't ever be greater than that
> > either.
> >
> > After those changes, the other two divisions are done as 32-bit
> > arithmetic operations, which are much faster.
> 
> Nice catch Arnd,  we originally fixed this with div_u64, but your
> solution looks wiser.
> does ktime_t gives time in a resolution same as timespec ?

ktime_t is a 64-bit nanosecond counter, so the resolution is the same
as ktime_get_ts64(), which is the "monotonic" equivalent of
getnstimeofday().

There are also variants that have the same resolution but are
less accurate and don't set the exact lower bits in order to
get a faster reading, but the above are all as accurate as the machine
allows.

	Arnd