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 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