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 <david(a)gibson.dropbear.id.au> wrote:Hm, ok.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.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