Re: [PATCH v2 18/18] tap: Improve handling of partial frame sends

[Stefano Brivio <sbrivio@redhat.com>]

On Fri,  9 Dec 2022 16:42:28 +1100
David Gibson <david@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@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 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