On Tue, Oct 1, 2024 at 6:22 PM Stephen Hemminger
<step...@networkplumber.org> wrote:
>
> On Tue, 1 Oct 2024 03:22:51 +0300
> Isaac Boukris <ibouk...@gmail.com> wrote:
>
> > diff --git a/lib/eal/windows/eal_timer.c b/lib/eal/windows/eal_timer.c
> > index b070cb7751..cfd6c267ac 100644
> > --- a/lib/eal/windows/eal_timer.c
> > +++ b/lib/eal/windows/eal_timer.c
> > @@ -49,13 +49,16 @@ rte_delay_us_sleep(unsigned int us)
> > }
> >
> > uint64_t
> > -get_tsc_freq(void)
> > +get_tsc_freq(uint64_t arch_hz)
> > {
> > LARGE_INTEGER t_start, t_end, elapsed_us;
> > LARGE_INTEGER frequency;
> > uint64_t tsc_hz;
> > uint64_t end, start;
> >
> > + if (arch_hz)
> > + return arch_hz;
> > +
> > QueryPerformanceFrequency(&frequency);
> >
> > QueryPerformanceCounter(&t_start);
> > --
>
> On Windows, I would not use arch_hz at all, since it is opaque how
> the Windows kernel determines the frequency, and best not to get
> skew.
Not sure I follow, currently the patch doesn't change the behavior for
Windows, and the Windows code is quite similar to the Linux one,
should we always prefer the measured value in Windows?
On the other hand, I think I should update the rounding commit to also
change the Windows code, there is no sense in 10MHz rounding there
either.
