From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 9F8615A0082 for ; Mon, 13 Feb 2023 04:12:05 +0100 (CET) Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4PFTsF6shkz4x5Z; Mon, 13 Feb 2023 14:12:01 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1676257921; bh=CfazBjzGGPPsXSyXQQzvF2BHpBuXuStjh1/FC4Br3zg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JGH0hWOopjkG1EDgidHIcZy+Ft+Ja7UXqOL85gMAGXieWEqer8YQ9/6UInZFkjrPx imnj0HIfFTv+wzm6T5fI2nQpastWrlNuMldcHnqQW6TusxG4n2nnETz2XHC90p6kcD qEy2L3eOtJuQvf67OIvla+dSRWPKKIRwYM675ycU= Date: Mon, 13 Feb 2023 13:24:58 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH] tap: Send frames after the first one in tap_send_frames_pasta() Message-ID: References: <20230213011211.1198729-1-sbrivio@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IfvRfHS3JpPwwqyh" Content-Disposition: inline In-Reply-To: <20230213011211.1198729-1-sbrivio@redhat.com> Message-ID-Hash: WGAY5BLQN5CS57E2XHBWJFB6SQ6IYNCV X-Message-ID-Hash: WGAY5BLQN5CS57E2XHBWJFB6SQ6IYNCV 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: passt-dev@passt.top X-Mailman-Version: 3.3.3 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: --IfvRfHS3JpPwwqyh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 13, 2023 at 02:12:11AM +0100, Stefano Brivio wrote: > ...instead of repeatedly sending out the first one in iov. >=20 > Fixes: e21ee41ac35a ("tcp: Combine two parts of pasta tap send path toget= her") > Signed-off-by: Stefano Brivio > --- > I just applied this, to unblock a series by David which was pending > for way too long. The commit reference in Fixes: refers to a commit > from said series which I'm pushing out together with this patch. Huh... how did this ever work even slightly. From that point of view, Reviewed-by: David Gibson > Posting anyway for reviews. That said.. >=20 > tap.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/tap.c b/tap.c > index af9bc15..716d887 100644 > --- a/tap.c > +++ b/tap.c > @@ -316,12 +316,13 @@ static void tap_send_frames_pasta(struct ctx *c, > { > size_t i; > =20 > - for (i =3D 0; i < n; i++) { > + for (i =3D 0; i < n; i++, iov++) { I quite dislike having multiple "counters" that need to be updated for each loop iteration (manual strength reduction. It's really easy to make a mistake in later changes and let the two values get out of sync - which is exactly what I did with the earlier change that introduced this bug. W.r.t. performance, I generally trust the compiler's automatic strength reduction to have a better idea of whether it will be worth it or not than my own guess. > if (write(c->fd_tap, (char *)iov->iov_base, iov->iov_len) < 0) { So, my *intention* on the older patch was to replace 'iov->' above with 'iov[i].' > debug("tap write: %s", strerror(errno)); > if (errno !=3D EAGAIN && errno !=3D EWOULDBLOCK) > tap_handler(c, c->fd_tap, EPOLLERR, NULL); > i--; > + iov--; > } > } > } --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --IfvRfHS3JpPwwqyh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmPpn2UACgkQzQJF27ox 2GdKXA/9Go8lZgB+guIlFl0GGqWooetHngGK/kR6fMq5Zg4uVPhntRe2WPX2Ei4M XYPSzGB9wsqZpU/Ec9vmvcJFD7cVAfvHzn1j7MUGlz7SdJowMLfWe0gmAvSL4uE1 IGkV9U6i4hHAmFe/a1Ir3zwrcmIrDDzDh9XnIXyUu345Y7Tc2/Gd/58qfnyC2lqX D53eru2MRGd/HSu18auiCCB//NCUbJntL9irUaNUPwx1hB9Zk6vEMSIpBPjjoYri Ug7h3g5g9d1IEOR781KT5gr9ZiJ1MFZAUo0j55h1VKg1M81645QgdysK7Qscpcmu x+JbXhk0jWZlFcIYi5dI37jcNdx1WIse4ZAyCkNYighogxI6iTu/Kgk/BGWRPelJ Ov9IYgYFXF0/MQqNn5bpWV1a7kv4Fw2xDzq+hT33G9qRcCmCBU7Ex1OP9sJkdnry z4tUxyyxqfGQ32D0FDiq1GIIdVNqBT0NIXFi3Xwnn3Mq7xMtjVsSYCajwfDOBA6x gL96va5zkyVV1eHVjSsitMp9BnXa7/6QM3mh8lw5ECYgIukiZmzsMbd5rF1RP0ax nZ8VhjthuKu7m8eb3D/grbmhEudjI2yS8+h0AOCrlpPxKpMW75fd0uvF0IPS1O0+ m2J8GHKGlCCHx1EKriMiznZm6Lq/kXc+q6leOcbba+RSxaGt5Es= =8zPC -----END PGP SIGNATURE----- --IfvRfHS3JpPwwqyh--