[PATCH v2 00/18] RFC: Unify and simplify tap send path
Although we have an abstraction for the "slow path" (DHCP, NDP) guest bound packets, the TCP and UDP forwarding paths write directly to the tap fd. However, it turns out how they send frames to the tap device is more similar than it originally appears. This series unifies the low-level tap send functions for TCP and UDP, and makes some clean ups along the way. This is based on my earlier outstanding series. Changes since v1: * Abstract tap header construction as well as frame send (a number of new patches) * Remove unneeded flags buf_bytes globals as well * Fix bug where we weren't correctly setting iov_len after the move to giving variable sized iovecs to send_frames(). David Gibson (18): pcap: Introduce pcap_frame() helper pcap: Replace pcapm() with pcap_multiple() tcp: Combine two parts of passt tap send path together tcp: Don't keep compute total bytes in a message until we need it tcp: Improve interface to tcp_l2_buf_flush() tcp: Combine two parts of pasta tap send path together tap, tcp: Move tap send path to tap.c util: Introduce hton*_constant() in place of #ifdefs tcp, udp: Use named field initializers in iov_init functions util: Parameterize ethernet header initializer macro tcp: Remove redundant and incorrect initialization from *_iov_init() tcp: Consolidate calculation of total frame size tap: Add "tap headers" abstraction tcp: Use abstracted tap header tap: Use different io vector bases depending on tap type udp: Use abstracted tap header udp: Use tap_send_frames() tap: Improve handling of partial frame sends dhcpv6.c | 50 +++-------- pcap.c | 78 +++++------------ pcap.h | 3 +- tap.c | 123 +++++++++++++++++++++++++++ tap.h | 54 ++++++++++++ tcp.c | 254 +++++++++++++------------------------------------------ udp.c | 213 ++++++---------------------------------------- udp.h | 2 +- util.h | 47 ++-------- 9 files changed, 303 insertions(+), 521 deletions(-) -- 2.38.1
pcap(), pcapm() and pcapmm() duplicate some code, for the actual writing
to the capture file. The main purpose pf pcapm() and pcampp() not calling
pcap seems to be to avoid repeatedly calling gettimeofday(). We can
accomplish that while still sharing code by adding a new helper which
takes the packet timestamp as a parameter.
Signed-off-by: David Gibson
On Fri, 9 Dec 2022 16:42:11 +1100
David Gibson
pcap(), pcapm() and pcapmm() duplicate some code, for the actual writing to the capture file. The main purpose pf pcapm() and pcampp() not calling pcap seems to be to avoid repeatedly calling gettimeofday(). We can accomplish that while still sharing code by adding a new helper which takes the packet timestamp as a parameter.
Another purpose is to avoid logging errors for single messages in batches -- if something goes wrong with the log file, it gets noisy to the point of making passt unusable during throughput tests. Sure, it's quite unlikely to happen during normal operation -- still, should you re-spin, pcap_frame() could return errors and callers could abort early in case. -- Stefano
On Wed, Jan 04, 2023 at 06:45:03PM +0100, Stefano Brivio wrote:
On Fri, 9 Dec 2022 16:42:11 +1100 David Gibson
wrote: pcap(), pcapm() and pcapmm() duplicate some code, for the actual writing to the capture file. The main purpose pf pcapm() and pcampp() not calling pcap seems to be to avoid repeatedly calling gettimeofday(). We can accomplish that while still sharing code by adding a new helper which takes the packet timestamp as a parameter.
Another purpose is to avoid logging errors for single messages in batches -- if something goes wrong with the log file, it gets noisy to the point of making passt unusable during throughput tests.
Sure, it's quite unlikely to happen during normal operation -- still, should you re-spin, pcap_frame() could return errors and callers could abort early in case.
Good point, adjusted. -- 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
pcapm() captures multiple frames from a msghdr, however the only thing it
cares about in the msghdr is the list of buffers, where it assumes there is
one frame to capture per buffer. That's what we want for its single caller
but it's not the only obvious choice here (one frame per msghdr would
arguably make more sense in isolation). In addition pcapm() has logic
that only makes sense in the context of the passt specific path its called
from: it skips the first 4 bytes of each buffer, because those have the
qemu vnet_len rather than the frame proper.
Make this clearer by replacing pcapm() with pcap_multiple() which more
explicitly takes one struct iovec per frame, and parameterizes how much of
each buffer to skip (i.e. the offset of the frame within the buffer).
Signed-off-by: David Gibson
tcp_l2_buf_flush() open codes the "primary" send of message to the passt
tap interface, but calls tcp_l2_buf_flush_part() to handle the case of a
short send. Combine these two passt-specific operations into
tcp_l2_buf_flush_passt() which is a little cleaner and will enable furrther
cleanups.
Signed-off-by: David Gibson
tcp[46]_l2_buf_bytes keep track of the total number of bytes we have
queued to send to the tap interface. tcp_l2_buf_flush_passt() uses this
to determine if sendmsg() has sent all the data we requested, or whether
we need to resend a trailing portion.
However, the logic for finding where we're up to in the case of a short
sendmsg() can equally well tell whether we've had one at all, without
knowing the total number in advance. This does require an extra loop after
each sendmsg(), but it's doing simple arithmetic on values we've already
been accessing, and it leads to overall simpler code.
tcp[46]_l2_flags_buf_bytes were being calculated, but never used for
anything, so simply remove them.
Signed-off-by: David Gibson
On Fri, 9 Dec 2022 16:42:14 +1100
David Gibson
tcp[46]_l2_buf_bytes keep track of the total number of bytes we have queued to send to the tap interface. tcp_l2_buf_flush_passt() uses this to determine if sendmsg() has sent all the data we requested, or whether we need to resend a trailing portion.
In the subject: s/compute/computed/. -- Stefano
On Wed, Jan 04, 2023 at 06:45:08PM +0100, Stefano Brivio wrote:
On Fri, 9 Dec 2022 16:42:14 +1100 David Gibson
wrote: tcp[46]_l2_buf_bytes keep track of the total number of bytes we have queued to send to the tap interface. tcp_l2_buf_flush_passt() uses this to determine if sendmsg() has sent all the data we requested, or whether we need to resend a trailing portion.
In the subject: s/compute/computed/.
Fixed. -- 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
Currently this takes a msghdr, but the only thing we actually care about
in there in is the io vector. Make it take an io vector directly. We also
have a weird side effect of zeroing @buf_used. Just pass this by value
and zero it in the caller instead.
Signed-off-by: David Gibson
On Fri, 9 Dec 2022 16:42:15 +1100
David Gibson
Currently this takes a msghdr, but the only thing we actually care about in there in is the io vector. Make it take an io vector directly. We also
s/in is/is/, if you re-spin.
have a weird side effect of zeroing @buf_used. Just pass this by value and zero it in the caller instead.
That was done on purpose: call a "flush" function, and that will set the right value for @buf_used. On the other hand, after 3/18, I think both options are equally readable, and if you found it weird, so be it. -- Stefano
On Wed, Jan 04, 2023 at 06:45:16PM +0100, Stefano Brivio wrote:
On Fri, 9 Dec 2022 16:42:15 +1100 David Gibson
wrote: Currently this takes a msghdr, but the only thing we actually care about in there in is the io vector. Make it take an io vector directly. We also
s/in is/is/, if you re-spin.
Fixed.
have a weird side effect of zeroing @buf_used. Just pass this by value and zero it in the caller instead.
That was done on purpose: call a "flush" function, and that will set the right value for @buf_used.
Hm, I guess. It seemed odd to me because most of the rest of the management of the buf_used variables is open coded in the caller.
On the other hand, after 3/18, I think both options are equally readable, and if you found it weird, so be it.
More to the point I think the old way obstructed the changes I make later in the series. -- 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
tcp_l2_buf_flush() open codes the loop across each frame in a group, but
but calls tcp_l2_buf_write_one() to send each frame to the pasta tuntap
device. Combine these two pasta-specific operations into
tcp_l2_buf_flush_pasta() which is a little cleaner and will enable further
cleanups.
Signed-off-by: David Gibson
The functions which do the final steps of sending TCP packets on through
the tap interface - tcp_l2_buf_flush*() - no longer have anything that's
actually specific to TCP in them, other than comments and names. Move them
all to tap.c.
Signed-off-by: David Gibson
We have several places where we have fairly ugly #ifdefs on __BYTE_ORDER
where we need network order values in a constant expression (so we can't
use htons() or htonl()). We can do this more cleanly by using a single
__BYTE_ORDER ifdef to define htons_constant() and htonl_constant()
macros, then using those in all the other places.
Signed-off-by: David Gibson
Both the TCP and UDP iov_init functions have some large structure literals
defined in "field order" style. These are pretty hard to read since it's
not obvious what value corresponds to what field. Use named field style
initializers instead to make this clearer.
Signed-off-by: David Gibson
We have separate IPv4 and IPv6 versions of a macro to construct an
initializer for ethernet headers. However, now that we have htons_constant
it's easy to simply paramterize this with the ethernet protocol number.
Signed-off-by: David Gibson
tcp_sock[46]_iov_init() initialize the length of each iovec buffer to
MSS_DEFAULT. That will always be overwritten before use in
tcp_data_to_tap, so it's redundant. It also wasn't correct, because it
didn't correctly account for the header lengths in all cases.
Signed-off-by: David Gibson
tcp_l2_buf_fill_headers() returns the size of the generated frame including
the ethernet header. The caller then adds on the size of the vnet_len
field to get the total frame size to be passed to the tap device.
Outside the tap code, though, we never care about the ethernet header size
only the final total size we need to put into an iovec. So, consolidate
the total frame size calculation within tcp_l2_buf_fill_headers().
Signed-off-by: David Gibson
Currently both the TCP and UDP code need to deal in various places with the
details of the L2 headers, and also the tap-specific "vnet_len" header.
This makes abstracting the tap interface to new backends (e.g. vhost-user
or tun) more difficult.
To improve this abstraction, create a new 'tap_hdr' structure which
represents both L2 (always Ethernet at the moment, but might be vary in
future) and any additional tap specific headers (such as the qemu socket's
vnet_len field). Provide helper functions and macros to initialize, update
and use it.
Signed-off-by: David Gibson
Update the TCP code to use the tap layer abstractions for initializing and
updating the L2 and lower headers. This will make adding other tap
backends in future easier.
Signed-off-by: David Gibson
Currently tap_send_frames() expects the frames it is given to include the
vnet_len field, even in pasta mode which doesn't use it (although it need
not be initialized in that case). To match, tap_iov_base() and
tap_iov_len() construct the frame in that way.
This will inconvenience future changes, so alter things to set the buffers
to include just the frame needed by the tap backend type.
Signed-off-by: David Gibson
Update the UDP code to use the tap layer abstractions for initializing and
updating the L2 and lower headers. This will make adding other tap
backends in future easier.
Signed-off-by: David Gibson
To send frames on the tap interface, the UDP uses a fairly complicated two
level batching. First multiple frames are gathered into a single "message"
for the qemu stream socket, then multiple messages are send with
sendmmsg(). We now have tap_send_frames() which already deals with sending
a number of frames, including batching and handling partial sends. Use
that to considerably simplify things.
This does make a couple of behavioural changes:
* We no longer split messages to keep them under 64kiB, which comments
say is necessary. However the TCP code didn't have equivalent code, so
either this isn't actually needed, or we should implement for both
(which is now easier since it can be done in one place).
* Previously when we got a partial send on UDP, we would resend the
remainder of the entire "message", including multiple frames. The
common code now only resends the remainder of a single frame, simply
dropping any frames which weren't even partially sent. This is what
TCP always did and is probably a better idea for UDP too.
Signed-off-by: David Gibson
On Fri, 9 Dec 2022 16:42:27 +1100
David Gibson
To send frames on the tap interface, the UDP uses a fairly complicated two level batching. First multiple frames are gathered into a single "message" for the qemu stream socket, then multiple messages are send with sendmmsg(). We now have tap_send_frames() which already deals with sending a number of frames, including batching and handling partial sends. Use that to considerably simplify things.
This does make a couple of behavioural changes: * We no longer split messages to keep them under 64kiB, which comments say is necessary. However the TCP code didn't have equivalent code, so either this isn't actually needed, or we should implement for both (which is now easier since it can be done in one place).
That used to be SHRT_MAX (32 KiB - 1), not 64 KiB. For some reason, if I sent messages with multiple frames, with any one of them larger than 32 KiB, qemu used to close the connection. But it looks like this was caused by some issue in the handling of short sends rather than an issue in qemu, especially given that, with this series applied, I don't hit the original issue (and I could predictably reproduce it earlier). -- Stefano
On Wed, Jan 04, 2023 at 06:45:25PM +0100, Stefano Brivio wrote:
On Fri, 9 Dec 2022 16:42:27 +1100 David Gibson
wrote: To send frames on the tap interface, the UDP uses a fairly complicated two level batching. First multiple frames are gathered into a single "message" for the qemu stream socket, then multiple messages are send with sendmmsg(). We now have tap_send_frames() which already deals with sending a number of frames, including batching and handling partial sends. Use that to considerably simplify things.
This does make a couple of behavioural changes: * We no longer split messages to keep them under 64kiB, which comments say is necessary. However the TCP code didn't have equivalent code, so either this isn't actually needed, or we should implement for both (which is now easier since it can be done in one place).
That used to be SHRT_MAX (32 KiB - 1), not 64 KiB. For some reason, if I sent messages with multiple frames, with any one of them larger than 32 KiB, qemu used to close the connection.
But it looks like this was caused by some issue in the handling of short sends rather than an issue in qemu, especially given that, with this series applied, I don't hit the original issue (and I could predictably reproduce it earlier).
Right, I already updated the commit messages and some comments based on the discussion we had last night. -- 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
In passt mode, when writing frames to the qemu socket, we might get a short
send. If we ignored this and carried on, the qemu socket would get out of
sync, because the bytes we actually sent wouldn't correspond to the length
header we already sent. tap_send_frames_passt() handles that by doing a
a blocking send to complete the message, but it has a few flaws:
* We only attempt to resend once: although it's unlikely in practice,
nothing prevents the blocking send() from also being short
* We print a debug error if send() returns non-zero.. but send() returns
the number of bytes sent, so we actually want it to return the length
of the remaining data.
Correct those flaws and also be a bit more thorough about reporting
problems here.
Signed-off-by: David Gibson
On Fri, 9 Dec 2022 16:42:28 +1100
David Gibson
In passt mode, when writing frames to the qemu socket, we might get a short send. If we ignored this and carried on, the qemu socket would get out of sync, because the bytes we actually sent wouldn't correspond to the length header we already sent. tap_send_frames_passt() handles that by doing a a blocking send to complete the message, but it has a few flaws: * We only attempt to resend once: although it's unlikely in practice, nothing prevents the blocking send() from also being short * We print a debug error if send() returns non-zero.. but send() returns the number of bytes sent, so we actually want it to return the length of the remaining data.
Correct those flaws and also be a bit more thorough about reporting problems here.
Signed-off-by: David Gibson
--- tap.c | 51 ++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 38 insertions(+), 13 deletions(-) diff --git a/tap.c b/tap.c index 5ec6b70..4fb27ca 100644 --- a/tap.c +++ b/tap.c @@ -326,13 +326,39 @@ static void tap_send_frames_pasta(struct ctx *c, } }
+/** + * tap_send_remainder() - Send remainder of a partiall sent frame
s/partiall/partially/
+ * @c: Execution context + * @iov: Partially sent buffer + * @offset: Number of bytes already sent from @iov + * + * #syscalls:passt sendto
We should probably drop this, it's actually send(2) on armv6/armv7 and ppc64le, sendto(2) otherwise -- initially I sprinkled those annotations all over the place to show where specific calls were issued (and make it easier to drop them from the filter if calls disappeared) but I think it's not really practical for send(3). -- Stefano
On Wed, Jan 04, 2023 at 06:45:33PM +0100, Stefano Brivio wrote:
On Fri, 9 Dec 2022 16:42:28 +1100 David Gibson
wrote: In passt mode, when writing frames to the qemu socket, we might get a short send. If we ignored this and carried on, the qemu socket would get out of sync, because the bytes we actually sent wouldn't correspond to the length header we already sent. tap_send_frames_passt() handles that by doing a a blocking send to complete the message, but it has a few flaws: * We only attempt to resend once: although it's unlikely in practice, nothing prevents the blocking send() from also being short * We print a debug error if send() returns non-zero.. but send() returns the number of bytes sent, so we actually want it to return the length of the remaining data.
Correct those flaws and also be a bit more thorough about reporting problems here.
Signed-off-by: David Gibson
--- tap.c | 51 ++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 38 insertions(+), 13 deletions(-) diff --git a/tap.c b/tap.c index 5ec6b70..4fb27ca 100644 --- a/tap.c +++ b/tap.c @@ -326,13 +326,39 @@ static void tap_send_frames_pasta(struct ctx *c, } }
+/** + * tap_send_remainder() - Send remainder of a partiall sent frame
s/partiall/partially/
Fixed.
+ * @c: Execution context + * @iov: Partially sent buffer + * @offset: Number of bytes already sent from @iov + * + * #syscalls:passt sendto
We should probably drop this, it's actually send(2) on armv6/armv7 and ppc64le, sendto(2) otherwise -- initially I sprinkled those annotations all over the place to show where specific calls were issued (and make it easier to drop them from the filter if calls disappeared) but I think it's not really practical for send(3).
Heh, right. Done. -- 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
On Fri, 9 Dec 2022 16:42:10 +1100
David Gibson
Although we have an abstraction for the "slow path" (DHCP, NDP) guest bound packets, the TCP and UDP forwarding paths write directly to the tap fd. However, it turns out how they send frames to the tap device is more similar than it originally appears.
This series unifies the low-level tap send functions for TCP and UDP, and makes some clean ups along the way.
This is based on my earlier outstanding series.
Other than the minor remarks I shared, this looks good to me, and it shows no functional or performance impact in tests. -- Stefano
participants (2)
-
David Gibson
-
Stefano Brivio