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

[Stefano Brivio <sbrivio@redhat.com>]

On Wed, 14 Dec 2022 12:42:14 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

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

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