> From: Stephen Hemminger [mailto:[email protected]] > Sent: Monday, 2 February 2026 19.44 > > On Thu, 29 Jan 2026 10:00:15 +0100 > Morten Brørup <[email protected]> wrote: > > > > This and previous proposal to prefetch have no impact on > performance. > > > Rolled a simple perf test and all three versions come out the same. > > > > Please be aware that many test cases are inadvertently designed in a > way where mbufs unintendedly are hot in the cache, so prefetching does > not provide the expected performance gain. > > E.g. when working on a newly allocated mbuf, the mbuf should be cold. > > But if it came from the mempool cache, and was recently worked on and > then freed into the mempool cache, then it will be hot. > > > > > The bottleneck is not here, probably at system call and copies now. > > > > The most important bottleneck might be elsewhere. > > But this optimization might not be as irrelevant as the test results > indicate. > > > > Anyway, I agree that dropping the patch (for now) makes sense. > > I doubt pre-fetch will matter much in a driver like this because: > - on tx the data is still in cache since just setup by caller If the packet has been sitting in a queue, e.g. for QoS buffering, it may have been evicted from the cache. > - on rx the data is still in cache since kernel just copied > it into the buffer. If there's any delay between the signaling and the handling, it could be evicted from the cache in the meantime. (The delay could come from e.g. the handling CPU core being busy with something else before handling the RX ready signal.) And it could be in the cache of a different CPU core.
Anyway, I still agree with dropping the patch for now, since testing shows no difference.
