On Fri, 9 Dec 2022 16:42:28 +1100 David Gibson <david(a)gibson.dropbear.id.au> 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 <david(a)gibson.dropbear.id.au> --- 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 frames/partiall/partially/+ * @c: Execution context + * @iov: Partially sent buffer + * @offset: Number of bytes already sent from @iov + * + * #syscalls:passt sendtoWe 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