On Wed, Jan 04, 2023 at 06:44:38PM +0100, Stefano Brivio wrote:
> On Wed,  4 Jan 2023 16:44:24 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
[snip]
> >  /**
> >   * udp_update_hdr4() - Update headers for one IPv4 datagram
> >   * @c:		Execution context
> > @@ -944,32 +898,53 @@ void udp_sock_handler(const struct ctx *c, union epoll_ref ref, uint32_t events,
> >  		      const struct timespec *now)
> >  {
> >  	/* For not entirely clear reasons (data locality?) pasta gets
> > -	 * better throughput if we receive the datagrams one at a
> > -	 * time.
> > +	 * better throughput if we receive tap datagrams one at a
> > +	 * atime.  For small splice datagrams throughput is slightly
> > +	 * better if we do batch, but it's slightly worse for large
> > +	 * splice datagrams.  Since we don't know before we receive
> > +	 * whether we'll use tap or splice, always go one at a time
> > +	 * for pasta mode.
> >  	 */
> >  	ssize_t n = (c->mode == MODE_PASST ? UDP_MAX_FRAMES : 1);
> >  	in_port_t dstport = ref.r.p.udp.udp.port;
> >  	bool v6 = ref.r.p.udp.udp.v6;
> > -	struct mmsghdr *sock_mmh;
> > +	struct mmsghdr *mmh_recv;
> > +	unsigned int i, m;
> > +	ssize_t n;
> 
> This doesn't build, you're redefining 'n' after the new version of 4/8.

Wow, that was super sloppy of me, sorry.  I'm going to blame not being
quite back into it after the holiday.  For whatever reason my brain
just skipped over even the most rudimentary testing here.

> I could drop this on merge (the rest of the series would be ready to
> merge) but as you usually prefer to respin anyway, I'll wait for that.

Yeah, I'll send a respin short.  Tested, this time :).

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