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