From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefano Brivio <sbrivio@redhat.com>
To: passt-dev@passt.top
Subject: Re: [PATCH 1/2] udp: Don't drop zero-length outbound UDP packets
Date: Fri, 09 Sep 2022 18:06:59 +0200
Message-ID: <20220909180659.7b6fe407@elisabeth>
In-Reply-To: <YxsX8IFvOePGi/xE@yekko>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3730209680831247614=="

--===============3730209680831247614==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 9 Sep 2022 20:39:44 +1000
David Gibson <david(a)gibson.dropbear.id.au> wrote:

> On Fri, Sep 09, 2022 at 11:26:58AM +0200, Stefano Brivio wrote:
> > On Fri,  9 Sep 2022 14:27:13 +1000
> > David Gibson <david(a)gibson.dropbear.id.au> wrote:
> >  =20
> > > udp_tap_handler() currently skips outbound packets if they have a paylo=
ad
> > > length of zero.  This is not correct, since in a datagram protocol zero
> > > length packets still have meaning. =20
> >=20
> > Right, nice catch. As far as I can tell it's an issue I added with
> > commit bb708111833e ("treewide: Packet abstraction with mandatory
> > boundary checks").
> >  =20
> > > Adjust this to correctly forward the zero-length packets by using a msg=
hdr
> > > with msg_iovlen =3D=3D 0.
> > >=20
> > > Bugzilla: https://bugs.passt.top/show_bug.cgi?id=3D19
> > >=20
> > > Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au>
> > > ---
> > >  udp.c | 10 +++++-----
> > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > >=20
> > > diff --git a/udp.c b/udp.c
> > > index c4ebecc..caa852a 100644
> > > --- a/udp.c
> > > +++ b/udp.c
> > > @@ -1075,19 +1075,19 @@ int udp_tap_handler(struct ctx *c, int af, cons=
t void *addr,
> > >  		uh_send =3D packet_get(p, i, 0, sizeof(*uh), &len);
> > >  		if (!uh_send)
> > >  			return p->count;
> > > +
> > > +		mm[i].msg_hdr.msg_name =3D sa;
> > > +		mm[i].msg_hdr.msg_namelen =3D sl;
> > > +		count++;
> > > +
> > >  		if (!len)
> > >  			continue;
> > > =20
> > >  		m[i].iov_base =3D (char *)(uh_send + 1);
> > >  		m[i].iov_len =3D len; =20
> >=20
> > I haven't tested this yet, but:
> >=20
> > - shouldn't iov_len be set to 0 (moving also this line before)? Note
> >   that I'm not initialising m
> >=20
> > - shouldn't iov_base point to NULL to avoid noise from valgrind? =20
>=20
> No, because with this change m[i] is entirely unreferenced by mm[].
>=20
> > Also:
> >  =20
> > > =20
> > > -		mm[i].msg_hdr.msg_name =3D sa;
> > > -		mm[i].msg_hdr.msg_namelen =3D sl;
> > > -
> > >  		mm[i].msg_hdr.msg_iov =3D m + i;
> > >  		mm[i].msg_hdr.msg_iovlen =3D 1; =20
> >=20
> > ...I guess we should still go through those even if the size is zero,
> > because we're appending a message. If we don't, I would expect some
> > subsequent messages in the batch to be dropped (as many as zero sized
> > packets we have). =20
>=20
> Here I'm relying on the fact that mm[] (unlike m[]) *is* initialized,
> so if we don't alter it here, msg_iov is NULL and msg_iovlen is 0.

> I was looking at removing that initialization, but I haven't gotten
> that working yet.

Oops, I see now.

So, I suppose that if you want to drop that initialisation, you might
need to zero msg_hdr.controllen as well.

And msg_hdr.control too: other than keeping valgrind happy, not leaking
random stuff to the kernel might make this marginally more secure.

That should be better than the huge memset() at the beginning, because
we're already writing to msg_iovlen anyway.

If you already tried that, though, I don't have any other quick idea.

By the way, I had a mechanism in place, just for TCP though, to avoid
reassigning those pointers and also length descriptors.

I got rid of it in commit 38fbfdbcb95d ("tcp: Get rid of iov with
cached MSS, drop sendmmsg(), add deferred flush") because it didn't
really help with throughput. I don't see any significant "userspace"
overhead on guest-to-host TCP paths with perf(1).

...maybe for UDP that's different, I haven't focused that much on UDP
performance.

> > That is, I suppose we could just drop the continue statement on if
> > (!len) above -- but, again, I haven't tested it. =20
>=20
> My first version actually did that, so it also works, but I think
> setting msg_iovlen to 0 is a bit neater.

Right. Maybe it was just me being thick, or perhaps that could use a
comment:

		/* Zero-length packet: don't use any buffer, msg_iovlen is 0 */
		if (!len)
			continue;

--=20
Stefano


--===============3730209680831247614==--