From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH v2 17/18] udp: Use tap_send_frames()
Date: Wed, 4 Jan 2023 18:45:25 +0100 [thread overview]
Message-ID: <20230104184525.31fc2f87@elisabeth> (raw)
In-Reply-To: <20221209054228.4085990-18-david@gibson.dropbear.id.au>
On Fri, 9 Dec 2022 16:42:27 +1100
David Gibson <david@gibson.dropbear.id.au> 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).
--
Stefano
next prev parent reply other threads:[~2023-01-04 17:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 5:42 [PATCH v2 00/18] RFC: Unify and simplify tap send path David Gibson
2022-12-09 5:42 ` [PATCH v2 01/18] pcap: Introduce pcap_frame() helper David Gibson
2023-01-04 17:45 ` Stefano Brivio
2023-01-05 4:47 ` David Gibson
2022-12-09 5:42 ` [PATCH v2 02/18] pcap: Replace pcapm() with pcap_multiple() David Gibson
2022-12-09 5:42 ` [PATCH v2 03/18] tcp: Combine two parts of passt tap send path together David Gibson
2022-12-09 5:42 ` [PATCH v2 04/18] tcp: Don't keep compute total bytes in a message until we need it David Gibson
2023-01-04 17:45 ` Stefano Brivio
2023-01-05 4:48 ` David Gibson
2022-12-09 5:42 ` [PATCH v2 05/18] tcp: Improve interface to tcp_l2_buf_flush() David Gibson
2023-01-04 17:45 ` Stefano Brivio
2023-01-05 4:53 ` David Gibson
2022-12-09 5:42 ` [PATCH v2 06/18] tcp: Combine two parts of pasta tap send path together David Gibson
2022-12-09 5:42 ` [PATCH v2 07/18] tap, tcp: Move tap send path to tap.c David Gibson
2022-12-09 5:42 ` [PATCH v2 08/18] util: Introduce hton*_constant() in place of #ifdefs David Gibson
2022-12-09 5:42 ` [PATCH v2 09/18] tcp, udp: Use named field initializers in iov_init functions David Gibson
2022-12-09 5:42 ` [PATCH v2 10/18] util: Parameterize ethernet header initializer macro David Gibson
2022-12-09 5:42 ` [PATCH v2 11/18] tcp: Remove redundant and incorrect initialization from *_iov_init() David Gibson
2022-12-09 5:42 ` [PATCH v2 12/18] tcp: Consolidate calculation of total frame size David Gibson
2022-12-09 5:42 ` [PATCH v2 13/18] tap: Add "tap headers" abstraction David Gibson
2022-12-09 5:42 ` [PATCH v2 14/18] tcp: Use abstracted tap header David Gibson
2022-12-09 5:42 ` [PATCH v2 15/18] tap: Use different io vector bases depending on tap type David Gibson
2022-12-09 5:42 ` [PATCH v2 16/18] udp: Use abstracted tap header David Gibson
2022-12-09 5:42 ` [PATCH v2 17/18] udp: Use tap_send_frames() David Gibson
2023-01-04 17:45 ` Stefano Brivio [this message]
2023-01-05 4:54 ` David Gibson
2022-12-09 5:42 ` [PATCH v2 18/18] tap: Improve handling of partial frame sends David Gibson
2023-01-04 17:45 ` Stefano Brivio
2023-01-05 4:57 ` David Gibson
2023-01-04 17:45 ` [PATCH v2 00/18] RFC: Unify and simplify tap send path Stefano Brivio
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=20230104184525.31fc2f87@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
/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).