Re: [PATCH v3 00/18] RFC: Unify and simplify tap send path

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(a)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