mirror of
https://github.com/torvalds/linux.git
synced 2026-08-05 06:47:51 +02:00
4022f92a2e
The rss_ctx test has gotten pretty flaky after I increased the queue count in NIPA 2->3. Not 100% clear why. We get a lot of failures in the rss_ctx.test_hitless_key_update case. Looking closer it appears that the failures are mostly due to startup costs. I measured the following timing for ethtool -X: - python cmd(shell=True) : 150-250msec - python cmd(shell=False) : 50- 70msec - timed in bash : 45- 55msec - YNL Netlink call : 2- 4msec - .set_rxfh callback : 1- 2msec The target in the test was set to 200msec. We were mostly measuring ethtool startup cost it seems. Switch to YNL since it's 100x faster. Lower the pass criteria to 150msec, no real science behind this number but we removed some overhead, drivers which previously passed 200msec should easily pass 150msec now. Separately we should probably follow up on defaulting to shell=False, when script doesn't explicitly ask for True, because the overhead is rather significant. Switch from _rss_key_rand() to random.randbytes(), YNL takes a binary array rather than array of ints. Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250901173139.881070-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|---|---|---|
| .. | ||
| accounting | ||
| arch | ||
| bootconfig | ||
| bpf | ||
| build | ||
| certs | ||
| cgroup | ||
| counter | ||
| crypto | ||
| debugging | ||
| firewire | ||
| firmware | ||
| gpio | ||
| hv | ||
| iio | ||
| include | ||
| kvm/kvm_stat | ||
| laptop | ||
| leds | ||
| lib | ||
| memory-model | ||
| mm | ||
| net | ||
| objtool | ||
| pcmcia | ||
| perf | ||
| power | ||
| rcu | ||
| sched | ||
| sched_ext | ||
| scripts | ||
| sound | ||
| spi | ||
| testing | ||
| thermal | ||
| time | ||
| tracing | ||
| usb | ||
| verification | ||
| virtio | ||
| wmi | ||
| workqueue | ||
| writeback | ||
| Makefile | ||