[PATCH iwl-net] idpf: decrease statistics refresh interval

[PATCH iwl-net] idpf: decrease statistics refresh interval

[Danny Gonzalez]

The default 10s statistics refresh interval is too slow for real-time
monitoring and causes network selftests (e.g., uso.py) to fail when
verifying traffic immediately after transmission.

A 10s delay also causes aliasing in telemetry tools polling at shorter
intervals (e.g., 5s), leading to inaccurate rate calculations on
high-throughput NICs.

Decrease the refresh interval to 250ms to ensure fresh stats and fix
test failures.

Tested: drivers/net/hw:uso.py now passes
Fixes: a251eee62133 ("idpf: add SRIOV support and other ndo_ops")
Signed-off-by: Danny Gonzalez <digonzal@google.com>
---
 drivers/net/ethernet/intel/idpf/idpf_lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c b/drivers/net/ethernet/intel/idpf/idpf_lib.c
index cf966fe6c759..e2890d219431 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_lib.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c
@@ -1364,7 +1364,7 @@ void idpf_statistics_task(struct work_struct *work)
 	}
 
 	queue_delayed_work(adapter->stats_wq, &adapter->stats_task,
-			   msecs_to_jiffies(10000));
+			   msecs_to_jiffies(250));
 }
 
 /**
-- 
2.54.0.1099.g489fc7bff1-goog

Re: [PATCH iwl-net] idpf: decrease statistics refresh interval

[Brian Vazquez]

Tested-by: Brian Vazquez <brianvv@google.com>

Before patch:

# sar -n DEV 1  | grep eth1
08:09:51         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:09:52         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:09:53         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:09:54         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:09:55         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:09:56         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:09:57         eth1   4225.00   1801.00    736.18   1125.49
0.00      0.00      0.00      0.00
08:09:58         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:09:59         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:10:00         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:10:01         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:10:02         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:10:03         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:10:04         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:10:05         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:10:06         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:10:07         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00
08:10:08         eth1   3788.00   1435.00    628.26    535.24
0.00      0.00      0.00      0.00

After patch (you can now see background traffic reported right away!):

# sar -n DEV 1 | grep eth1
08:08:33         eth1    527.00    443.00    261.74     76.69
0.00      0.00      0.00      0.00
08:08:34         eth1    440.00    423.00    101.89     78.75
0.00      0.00      0.00      0.00
08:08:35         eth1    356.00    353.00     68.68     57.02
0.00      0.00      0.00      0.00
08:08:36         eth1    437.00    462.00    114.18    124.07
0.00      0.00      0.00      0.00
08:08:37         eth1    377.00    383.00     61.40     65.97
0.00      0.00      0.00      0.00
08:08:38         eth1    335.00    337.00     83.08     75.39
0.00      0.00      0.00      0.00
08:08:39         eth1    387.00    392.00     58.95     74.58
0.00      0.00      0.00      0.00
08:08:40         eth1    351.00    371.00     51.39    103.25
0.00      0.00      0.00      0.00
08:08:41         eth1    339.00    338.00     55.38     54.91
0.00      0.00      0.00      0.00
08:08:42         eth1    324.00    328.00     54.15     55.71
0.00      0.00      0.00      0.00


On Wed, Jun 10, 2026 at 8:24 PM Danny Gonzalez <digonzal@google.com> wrote:
>
> The default 10s statistics refresh interval is too slow for real-time
> monitoring and causes network selftests (e.g., uso.py) to fail when
> verifying traffic immediately after transmission.
>
> A 10s delay also causes aliasing in telemetry tools polling at shorter
> intervals (e.g., 5s), leading to inaccurate rate calculations on
> high-throughput NICs.
>
> Decrease the refresh interval to 250ms to ensure fresh stats and fix
> test failures.
>
> Tested: drivers/net/hw:uso.py now passes
> Fixes: a251eee62133 ("idpf: add SRIOV support and other ndo_ops")
> Signed-off-by: Danny Gonzalez <digonzal@google.com>
> ---
>  drivers/net/ethernet/intel/idpf/idpf_lib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c b/drivers/net/ethernet/intel/idpf/idpf_lib.c
> index cf966fe6c759..e2890d219431 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_lib.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c
> @@ -1364,7 +1364,7 @@ void idpf_statistics_task(struct work_struct *work)
>         }
>
>         queue_delayed_work(adapter->stats_wq, &adapter->stats_task,
> -                          msecs_to_jiffies(10000));
> +                          msecs_to_jiffies(250));
>  }
>
>  /**
> --
> 2.54.0.1099.g489fc7bff1-goog
>

Re: [PATCH iwl-net] idpf: decrease statistics refresh interval

[Alexander Lobakin]

From: Danny Gonzalez <digonzal@google.com>
Date: Thu, 11 Jun 2026 00:24:37 +0000

> The default 10s statistics refresh interval is too slow for real-time
> monitoring and causes network selftests (e.g., uso.py) to fail when
> verifying traffic immediately after transmission.
> 
> A 10s delay also causes aliasing in telemetry tools polling at shorter
> intervals (e.g., 5s), leading to inaccurate rate calculations on
> high-throughput NICs.
> 
> Decrease the refresh interval to 250ms to ensure fresh stats and fix
> test failures.

Have you tried a bit more conservate value like 1s? Wouldn't it be
enough for tests to pass?

250 ms is also okay, just curious.

> 
> Tested: drivers/net/hw:uso.py now passes
> Fixes: a251eee62133 ("idpf: add SRIOV support and other ndo_ops")
> Signed-off-by: Danny Gonzalez <digonzal@google.com>

Thanks,
Olek

Re: [PATCH iwl-net] idpf: decrease statistics refresh interval

[Danny Gonzalez]

On Thu, Jun 11, 2026 at 8:57 AM Alexander Lobakin
<aleksander.lobakin@intel.com> wrote:
>
> From: Danny Gonzalez <digonzal@google.com>
> Date: Thu, 11 Jun 2026 00:24:37 +0000
>
> > The default 10s statistics refresh interval is too slow for real-time
> > monitoring and causes network selftests (e.g., uso.py) to fail when
> > verifying traffic immediately after transmission.
> >
> > A 10s delay also causes aliasing in telemetry tools polling at shorter
> > intervals (e.g., 5s), leading to inaccurate rate calculations on
> > high-throughput NICs.
> >
> > Decrease the refresh interval to 250ms to ensure fresh stats and fix
> > test failures.
>
> Have you tried a bit more conservate value like 1s? Wouldn't it be
> enough for tests to pass?
>
> 250 ms is also okay, just curious.

Yes, 1s also allows the tests to pass.

We have a preference for 250 ms since High-Freq Telemetry (1s poll)
1s driver refresh rate causes aliasing:

# sar -n DEV 1 | grep eth1
10:52:15         eth1    390.00    339.00     51.92     55.54
0.00      0.00      0.00      0.00
10:52:16         eth1    409.00    360.00     54.72     58.64
0.00      0.00      0.00      0.00
10:52:17         eth1      0.00      0.00      0.00      0.00
0.00      0.00      0.00      0.00

Thanks,
Danny


>
> >
> > Tested: drivers/net/hw:uso.py now passes
> > Fixes: a251eee62133 ("idpf: add SRIOV support and other ndo_ops")
> > Signed-off-by: Danny Gonzalez <digonzal@google.com>
>
> Thanks,
> Olek

Re: [PATCH iwl-net] idpf: decrease statistics refresh interval

[Alexander Lobakin]

From: Danny Gonzalez <digonzal@google.com>
Date: Thu, 11 Jun 2026 11:26:18 -0700

> On Thu, Jun 11, 2026 at 8:57 AM Alexander Lobakin
> <aleksander.lobakin@intel.com> wrote:
>>
>> From: Danny Gonzalez <digonzal@google.com>
>> Date: Thu, 11 Jun 2026 00:24:37 +0000
>>
>>> The default 10s statistics refresh interval is too slow for real-time
>>> monitoring and causes network selftests (e.g., uso.py) to fail when
>>> verifying traffic immediately after transmission.
>>>
>>> A 10s delay also causes aliasing in telemetry tools polling at shorter
>>> intervals (e.g., 5s), leading to inaccurate rate calculations on
>>> high-throughput NICs.
>>>
>>> Decrease the refresh interval to 250ms to ensure fresh stats and fix
>>> test failures.
>>
>> Have you tried a bit more conservate value like 1s? Wouldn't it be
>> enough for tests to pass?
>>
>> 250 ms is also okay, just curious.
> 
> Yes, 1s also allows the tests to pass.
> 
> We have a preference for 250 ms since High-Freq Telemetry (1s poll)
> 1s driver refresh rate causes aliasing:
> 
> # sar -n DEV 1 | grep eth1
> 10:52:15         eth1    390.00    339.00     51.92     55.54
> 0.00      0.00      0.00      0.00
> 10:52:16         eth1    409.00    360.00     54.72     58.64
> 0.00      0.00      0.00      0.00
> 10:52:17         eth1      0.00      0.00      0.00      0.00
> 0.00      0.00      0.00      0.00

Ack!

Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>

> 
> Thanks,
> Danny

Thanks,
Olek

Re: [PATCH iwl-net] idpf: decrease statistics refresh interval

[Tantilov, Emil S]

On 6/12/2026 2:29 AM, Alexander Lobakin wrote:
> From: Danny Gonzalez <digonzal@google.com>
> Date: Thu, 11 Jun 2026 11:26:18 -0700
> 
>> On Thu, Jun 11, 2026 at 8:57 AM Alexander Lobakin
>> <aleksander.lobakin@intel.com> wrote:
>>>
>>> From: Danny Gonzalez <digonzal@google.com>
>>> Date: Thu, 11 Jun 2026 00:24:37 +0000
>>>
>>>> The default 10s statistics refresh interval is too slow for real-time
>>>> monitoring and causes network selftests (e.g., uso.py) to fail when
>>>> verifying traffic immediately after transmission.
>>>>
>>>> A 10s delay also causes aliasing in telemetry tools polling at shorter
>>>> intervals (e.g., 5s), leading to inaccurate rate calculations on
>>>> high-throughput NICs.
>>>>
>>>> Decrease the refresh interval to 250ms to ensure fresh stats and fix
>>>> test failures.
>>>
>>> Have you tried a bit more conservate value like 1s? Wouldn't it be
>>> enough for tests to pass?
>>>
>>> 250 ms is also okay, just curious.
>>
>> Yes, 1s also allows the tests to pass.
>>
>> We have a preference for 250 ms since High-Freq Telemetry (1s poll)
>> 1s driver refresh rate causes aliasing:
>>
>> # sar -n DEV 1 | grep eth1
>> 10:52:15         eth1    390.00    339.00     51.92     55.54
>> 0.00      0.00      0.00      0.00
>> 10:52:16         eth1    409.00    360.00     54.72     58.64
>> 0.00      0.00      0.00      0.00
>> 10:52:17         eth1      0.00      0.00      0.00      0.00
>> 0.00      0.00      0.00      0.00
> 
> Ack!
> 
> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> 
>>
>> Thanks,
>> Danny
> 
> Thanks,
> Olek

Unfortunately this doesn't scale very well as it introduces a bit of an 
overhead for the virtchnl having to update stats at a higher frequency, 
which is why the delay was so big to begin with ... You can have 
multiple vports and thousands of VFs. We do have a different solution 
for this case in the OOT driver, where we only speed it up a bit when 
there is an actual request from the user via mod_delayed_work():
https://github.com/intel/ethernet-linux-idpf/blob/main/idpf/src/idpf_ethtool.c#L1735

which would be a better approach for this issue, IMHO.

Thanks,
Emil