Re: [PATCH 4/8] udp: Receive multiple datagrams at once on the pasta sock->tap path

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]