On Tue, Jan 24, 2023 at 10:20:43PM +0100, Stefano Brivio wrote:
> On Fri,  6 Jan 2023 11:43:04 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > Although we have an abstraction for the "slow path" (DHCP, NDP) guest
> > bound packets, the TCP and UDP forwarding paths write directly to the
> > tap fd.  However, it turns out how they send frames to the tap device
> > is more similar than it originally appears.
> > 
> > This series unifies the low-level tap send functions for TCP and UDP,
> > and makes some clean ups along the way.
> > 
> > This is based on my earlier outstanding series.
> 
> For some reason, performance tests consistently get stuck (both TCP and
> UDP, sometimes throughput, sometimes latency tests) with this series,
> and not without it, but I don't see any possible relationship with that.

Drat, I didn't encounter that.   Any chance you could bisect to figure
out which patch specifically seems to trigger it?

I wonder if this could be related to the stalls I'm debugging,
although those didn't appear on the perf tests and also occur on
main.  I have now discovered they seem to be masked by large socket
buffer sizes - more info at https://bugs.passt.top/show_bug.cgi?id=41

> I checked debug output and I couldn't find anything obviously wrong
> there. I just started checking packet captures now...

Hrm, probably not then.  The stalls I'm seeing are associated with
lots of partial sends.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson