On Tue, Dec 13, 2022 at 11:48:47PM +0100, Stefano Brivio wrote:
Sorry for the long delay here,
On Mon, 5 Dec 2022 19:14:21 +1100 David Gibson
wrote: Usually udp_sock_handler() will receive and forward multiple (up to 32) datagrams in udp_sock_handler(), then forward them all to the tap interface. For unclear reasons, though, when in pasta mode we will only receive and forward a single datagram at a time. Change it to receive multiple datagrams at once, like the other paths.
This is explained in the commit message of 6c931118643c ("tcp, udp: Receive batching doesn't pay off when writing single frames to tap").
I think it's worth re-checking the throughput now as this path is a bit different, but unfortunately I didn't include this in the "perf" tests :( because at the time I introduced those I wasn't sure it even made sense to have traffic from the same host being directed to the tap device.
The iperf3 runs were I observed this are actually the ones from the Podman demo. Ideally that case should be also checked in the perf/pasta_udp tests.
Hm, ok.
How fundamental is this for the rest of the series? I couldn't find any actual dependency on this but I might be missing something.
So the issue is that prior to this change in pasta we receive multiple frames at once on the splice path, but one frame at a time on the tap path. By the end of this series we can't do that any more, because we don't know before the recvmmsg() which one we'll be doing. -- 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