On Wed, 14 Dec 2022 12:42:14 +1100
David Gibson
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.
Oh, right, I see. Then let me add this path to the perf/pasta_udp test and check how relevant this is now, I'll get back to you in a bit. -- Stefano