From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202408 header.b=ayakInzq; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id DEA4B5A004C for ; Wed, 04 Sep 2024 05:18:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202408; t=1725419879; bh=De7xHTAqWwyutWM8tmGnKvhgImS/7ANwZCl48/uHwI0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ayakInzqGFMXKWafZVznuOy4m8tGxwpZ8b0xnkSecLOTvu+h1ZeCF7sbC5GG+6jzZ suzLq0uoJpNW32lPoXq/CHPOrB04ODP32ju3aPgo4CZMRqChZDK/+tE0h40LihHc26 LDN+AIICVuhNRxPaf2AP48Xh417YC5u7nxpDoo0DRaC0UbcDATLRjUdjkOaNw3A95D 4EDjGwg1WcG4+VdbdEY63DtSY3hrGgBbu3k5ysgiNBT/xa+tSXLcpOhe1QzdQz9UT/ x2Wds7tqXN98lSpCCzTFmxOFHegkBlrhA0OABuZcxh55l4y93rpOhA8WqI+3k/sNvW HhKx8IRZZfkZA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4Wz73W3kvCz4xGl; Wed, 4 Sep 2024 13:17:59 +1000 (AEST) Date: Wed, 4 Sep 2024 13:17:53 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 0/6] RFC: Clean up tap-side event handling Message-ID: References: <20240903120235.1688429-1-david@gibson.dropbear.id.au> <20240903212554.036da194@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0I8c4+rmaGbOGIMg" Content-Disposition: inline In-Reply-To: <20240903212554.036da194@elisabeth> Message-ID-Hash: U4DWRNS4AEF2GFYJHTX7YBWVAOLHEMRG X-Message-ID-Hash: U4DWRNS4AEF2GFYJHTX7YBWVAOLHEMRG 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.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: --0I8c4+rmaGbOGIMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 03, 2024 at 09:25:54PM +0200, Stefano Brivio wrote: > On Tue, 3 Sep 2024 22:02:29 +1000 > David Gibson wrote: >=20 > > This is a draft patch working towards adding EPOLLOUT handling to the > > tap code, which could then be used to "unstick" flows which have > > unsent data from the socket side. For now that's just a stub, but > > makes what I think are some worthwhile cleanups to the tap side event > > handling in the meantime. >=20 > Except for the issue in 3/6 and nits elsewhere, it all makes sense and > tap-side EPOLLOUT handling is definitely going to be an improvement. >=20 > I wonder if it's the right moment for this kind of series, though, in > terms of future bisections, as long as we're grappling with > https://github.com/containers/podman/issues/23686 and > https://bugs.passt.top/show_bug.cgi?id=3D94. Assuming, of course, that > this series doesn't fix anything. I don't think this series will fix anything as it stands. It is, indirectly, aimed at addressing bug 94. I'm struggling to figure out what to do with bug 94, because I find it almost impossible to reason about the current event masks in TCP. I'd really like to simplify them so it's clearer what's correct and not and I think the most obvious path to doing so is using EPOLLET all the time. That requires some sort of kick when the tap is ready to accept more data, hence this series as a prerequisite. > That is, once/if we come up with fixes for those, as they might involve > setting different event masks, I'd rather have those in *before* this > series, to avoid further noise in case we manage to break something > else with those hypothetical fixes. Right, I understand the impetus. Although as I said I find the current TCP event handling nigh-incomprehensible so I'm not as yet confident we can find a small fix without cleaning up the event handling more generally. That said, these changes to tap side event handling are a prerequisite / preliminary and shouldn't as yet really alter the TCP event flow. So I don't think this series will of itself make bisection harder, although follow on things based on it might. --=20 David Gibson (he or they) | 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 --0I8c4+rmaGbOGIMg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmbX0WAACgkQzQJF27ox 2GernQ//VIhq/We+PUCCLC5NLjCxVozi7KexsSUJrYYMK3XTRtBGN9/qxjUZSbiR LvwoAYyuHcx4U04DSBFaKtJTT/jvYmtxpQjJ6A9h8ifqrWZiXf4pwuRl/IMTlOY4 5yiMVISQfLBwor7fNxYEhzx+fj8pXbzab4PlN9AE4Wqd1qWbxfEwaItJ2QrREQmC H2TdsZXQoQH7Lp8Acd8n2WSk7nZXPcTCszQmyNp8ORpl0c7jRHZAW6dOVNAzcUR7 AnrgyO9PXvemcHWSc8HQhLdRQWxQ1u+xsohnoXQNigNuUqvRVrb/RubMP1EiD6kf 1OK/HxLKWkltCsJuV/qxjgodJdgF0dx3Az2/OlmAMVYKchm05pV/tp3ESCg2ITM7 ZDmJdIcLWouTokWZuQxFXU8p3Zfj5qmrDrkLw8J8Fn5MPt66TGQZRRPneURvVsKi kHe9ONrFrDe0IOTpqkqfNut41qspL++rfjNiL8ymq/gxAxHJgOugNRrUH5cmp2X3 9vUVkSql/oQBTeDb4GfWrva9tm48hDEMIws+Nqjc0xfUldFHyA3OYVVKMPhH1Oc/ ECcH/ndQfzpGK81G8gxrtftpMzwK2Ey2vAp+PM3SJI5iAytqcWyrSjLsVXA/MjzF zL9FeJS1Iz272XW113wZ6GkO/BLLFKPK/L01rIeIfFjZ/9VC4Io= =1u9d -----END PGP SIGNATURE----- --0I8c4+rmaGbOGIMg--