public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top
Subject: UDP "splicing" fairly broken :(
Date: Thu, 17 Nov 2022 16:07:32 +1100	[thread overview]
Message-ID: <Y3XBlHtGQZpyHHTG@yekko> (raw)

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

In preparation for trying to implement dual stack sockets for UDP,
I've been getting my head around how the UDP splicing works.  Alas,
I'm pretty sure that it's broken if there's not a one-to-one
correspondence between init side source ports and ns side destination
ports.  That will typically be the case, but given its UDP there's no
guarantee.

In addition, UDP servers in the ns will not see the correct port
numbers with getpeername().  That's also true of spliced TCP
connections (see https://bugs.passt.top/show_bug.cgi?id=39), but it's
more likely to matter for UDP (I don't know of any TCP protocols that
care about source port number on the server side, but there are some
common UDP protocols that have at least port number conventions on
both sides).

I can expand on the details later, but pasta will do the wrong thing
in at least some circumstances for both a single init side socket
sendto()ing packets to multiple different ports in the ns/guest and
multiple init side sockets send()ing to the same port in the ns/guest.

I think I know how to fix it, but it's not a trivial job.  So, the
question is do I embark on this now, or do I just remove UDP
"splicing" entirely for the time being (other than a minimum required
to make -U work)?  That would unblock dual stack UDP sockets and we
can attempt to reoptimize this later.

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

             reply	other threads:[~2022-11-17  5:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-17  5:07 David Gibson [this message]
2022-11-17  7:21 ` UDP "splicing" fairly broken :( Stefano Brivio
2022-11-17 10:30   ` David Gibson
2022-11-17 20:02     ` Stefano Brivio
2022-11-18  5:08       ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3XBlHtGQZpyHHTG@yekko \
    --to=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).