On Fri, 9 Dec 2022 16:42:27 +1100
David Gibson <david(a)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).