From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 23A705A026D for ; Wed, 8 Nov 2023 04:18:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1699413479; bh=TrU02kflO2p4V70DJhM6jlKZhU106kiIXpV9dchY5gU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p8pJCbo/vrqOhhNYMzACcMwyVJuK0LgSs/vbDO0dYJJ8iVsYAy2LhJIsIWXqoigzz DApuJU+vTVmdTD29+IZLSfX2aSWMJWROSJ1vAwmD3YHh2zxpt7BOzk+MxfoxbeEcmY 9EMx4VqoPOc55ZZlam9SxJ28MG4Q8+Fa5S+l6pbk= Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4SQ9JR0J8Zz4xPL; Wed, 8 Nov 2023 14:17:59 +1100 (AEDT) From: David Gibson To: passt-dev@passt.top, Stefano Brivio Subject: [PATCH 1/2] tap, pasta: Handle incomplete tap sends for pasta too Date: Wed, 8 Nov 2023 14:17:53 +1100 Message-ID: <20231108031754.2670078-2-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231108031754.2670078-1-david@gibson.dropbear.id.au> References: <20231108031754.2670078-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: BXNAQ623EDFWUFJQYRIIMZHQX736Z4MB X-Message-ID-Hash: BXNAQ623EDFWUFJQYRIIMZHQX736Z4MB X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: David Gibson X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Since a469fc39 ("tcp, tap: Don't increase tap-side sequence counter for dropped frames") we've handled more gracefully the case where we get data from the socket side, but are temporarily unable to send it all to the tap side (e.g. due to full buffers). That code relies on tap_send_frames() returning the number of frames it successfully sent, which in turn gets it from tap_send_frames_passt() or tap_send_frames_pasta(). While tap_send_frames_passt() has returned that information since b62ed9ca ("tap: Don't pcap frames that didn't get sent"), tap_send_frames_pasta() always returns as though it succesfully sent every frame. However there certainly are cases where it will return early without sending all frames. Update it report that properly, so that the calling functions can handle it properly. Signed-off-by: David Gibson --- tap.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tap.c b/tap.c index 3a938f3..00622e7 100644 --- a/tap.c +++ b/tap.c @@ -330,8 +330,6 @@ static size_t tap_send_frames_pasta(const struct ctx *c, case EWOULDBLOCK: #endif case EINTR: - i--; - break; case ENOBUFS: case ENOSPC: break; @@ -341,7 +339,7 @@ static size_t tap_send_frames_pasta(const struct ctx *c, } } - return n; + return i; } /** -- 2.41.0