Re: [PATCH] xen/netfront: Fix TX response spurious interrupts

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Wed, Jul 16, 2025 at 07:47:48AM +0000, Anthoine Bourgeois wrote:
> On Tue, Jul 15, 2025 at 12:19:34PM -0700, Elliott Mitchell wrote:
> >On Tue, Jul 15, 2025 at 08:21:40AM +0000, Anthoine Bourgeois wrote:
> >> On Mon, Jul 14, 2025 at 05:37:51PM -0700, Elliott Mitchell wrote:
> >> >On Mon, Jul 14, 2025 at 07:11:06AM +0000, Anthoine Bourgeois wrote:
> >> >> On Fri, Jul 11, 2025 at 05:33:43PM +0200, Juergen Gross wrote:
> >> >> >On 10.07.25 18:11, Anthoine Bourgeois wrote:
> >> >
> >> >Tested on a VM which this could be tried on.
> >> >
> >> >Booting was successful, network appeared to function as it had been.
> >> >Spurious events continued to occur at roughly the same interval they had
> >> >been.
> >> >
> >> >I can well believe this increases Xen network performance and may
> >> >reduce the occurrence of spurious interrupts, but it certainly doesn't
> >> >fully fix the problem(s).  Appears you're going to need to keep digging.
> >> >
> >> >I believe this does count as Tested-by since I observed no new ill
> >> >effects.  Just the existing ill effects aren't fully solved.
> >>
> >> Thank you for the test!
> >> Could you send me the domU/dom0 kernel version and xen version ?
> >
> >I tend to follow Debian, so kernel 6.1.140 and 4.17.6.  What may be
> >more notable is AMD processor.
> >
> >When initially reported, it was reported as being more severe on systems
> >with AMD processors.  I've been wondering about the reason(s) behind
> >that.
> 
> AMD processors could make a huge difference. On Ryzen, this patch could
> almost double the bandwidth and on Epyc close to nothing with low
> frequency models, there is another bottleneck here I guess.
> On which one do you test?
> 
> Do you know there is also a workaround on AMD processors about remapping
> grant tables as WriteBack?
> Upstream patch is 22650d605462 from XenServer.
> The test package for XCP-ng with the patch:
> https://xcp-ng.org/forum/topic/10943/network-traffic-performance-on-amd-processors
> 

Why are you jumping onto mostly unrelated issues when the current bug is
unfinished?

Spurious events continue to be observed on the network backend.  Spurious
events are also being observed on block and PCI backends.  You identified
one cause, but others remain.

(I'm hoping the next one effects all the back/front ends; the PCI backend
is a bigger issue for me)

Should add, one VM being observed with these issue(s) is using 6.12.38.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445