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=buZWwkC1; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id EBCB15A004E for ; Thu, 05 Sep 2024 02:35:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202408; t=1725496522; bh=kLwFKLBt7pf9C90gGX43WsgO9WgcN4A2FxbK9aT5sJM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=buZWwkC1LlM34l1I0WC+jt2XTCPF8nBzHhLEOWuLrf83ZhJjG/BtNLTgmblsJtEGd VQoH72QmJ43hPO3KVe9XQBFsa8q+6Zj4SNID0B7YWeMPjfJ8PVTibOoVna/wkmj4qs 7DnH9tfcWuSU//VrZn3P8qmX/BTu/vooXlM02Ol3PlNjQPR+Vq+p04180GL0J6C+uF GhfhoHv08x1CEbtPOVNiyqCgDGvifJyCdviGYjWLgk2ylNnDhUwT42h0NhhT7IhKHD S1IyKbaBO/JwfVWlBMwZjABNFCgmzMxPe8o+qNO8JKaKGMtLrYbWqoclulJt599PQ3 FLPdRZGQqBUbA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4WzgPQ3x0Rz4x0K; Thu, 5 Sep 2024 10:35:22 +1000 (AEST) Date: Thu, 5 Sep 2024 10:35:14 +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> <20240904191922.146bb53e@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SCnlG7Tspp7xPBPC" Content-Disposition: inline In-Reply-To: <20240904191922.146bb53e@elisabeth> Message-ID-Hash: MQKNP2MA4LBGPLQZ4BW6RXY4OKV7YJGP X-Message-ID-Hash: MQKNP2MA4LBGPLQZ4BW6RXY4OKV7YJGP 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: --SCnlG7Tspp7xPBPC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 04, 2024 at 07:19:22PM +0200, Stefano Brivio wrote: > On Wed, 4 Sep 2024 13:17:53 +1000 > David Gibson wrote: >=20 > > 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 t= he > > > > 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 eve= nt > > > > handling in the meantime. =20 > > >=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. =20 > >=20 > > 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. >=20 > I don't see at the moment anything indicating TCP issues other than the > one you addressed with your tentative debug patch at: >=20 > https://passt.top/passt/commit/?h=3Dpodman23686&id=3D026fb71d1dde60135d= 95741552906fd5320384bc >=20 > Given that, with that patch, we had at least another report of event > storms, this time on UDP, that is, the one from: >=20 > https://github.com/containers/podman/issues/23686#issuecomment-23249450= 10 >=20 > I shared this other one on top: >=20 > https://passt.top/passt/commit/?h=3Dpodman23686&id=3D0c6c20dee5c24bd324= 834a99f409ad43c50812ae Ah, nice. > > 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. >=20 > Sure, it's going to be simpler and more robust, but on the other hand > we wouldn't notice these kind of issues. Uh.. I'm confused. In what way would we not notice issues, other than the issues not existing which.. would be good, right? > > > That is, once/if we come up with fixes for those, as they might invol= ve > > > 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. =20 > >=20 > > 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. >=20 > I'm not sure either, but I don't think we have any indication, at the > moment, that any of the issues from those two tickets have anything to > do with TCP event handling (minus the one you tentatively fixed). Right, this reasoning is pretty much specific to the EPOLLRDHUP storm. I may have written some of the descriptions before registering that the EPOLLERR storm was UDP and therefore unrelated. > > 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 > I understand that they shouldn't alter it, but if we missed something > subtle and they actually do, they'll make bisection more complicated. I guess. Seems pretty unlikely to me given this doesn't touch the TCP events themselves. > If this series is only needed for switching TCP sockets to EPOLLET > (well, minus 4/6, which is a fix on its own), maybe we could wait until > you have the whole thing ready (and, hopefully, we manage to fix those > two tickets meanwhile)? Right, I'm ok to wait on this until I have the whole picture including TCP event masks as well. That's kind of why it's an RFC. --=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 --SCnlG7Tspp7xPBPC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmbY/MEACgkQzQJF27ox 2Gdadg/8D1ulqbSViEoEeGcwYXAuR+Gw2v3B6bs+shImdBSg0UbdVQstxXNcmBU0 M6t1qE/ocESLOSuL0s+2ifXZOm/YStciv9KjNR3nVnqMMkxc2yJaAaoXR/enfu5M Ua27hlxAI0rMD0RTQIPH9VWxMThzHgsygw+DK1jq1YKaDYFazy/2tQ+7vtqqUb3/ Zx59XypLwsLekVO12H5OL7wsaQ8mKzGkfohUC2S5X57FIWjfa944FTUP6+P/F2K8 Fm+1XfHaGkYNDP3qgf8NmTRmk6hAir/MZ8ntOS148sRlZYwU361cN2qMcE+nNido t0mp45qnl6Qxy+clJliwrCc8bs4Vb2sddyOisr90kL5UYAnhmM/QSxpNewEfytmL E4iN0uRbKmziM2FTFePlTCl4MClw42mlLBCMUre7Fe7TIz4c3+taJRU30c49ySEM 7djTgRNku/bdWWdmV9RCACK+iLfQCVqrdSDM9GkqXw2MRxQ6PPjhjJPNLmW2quqj kukNSVLgtRim697bDmR7rV80ZajoSzWIXyy+Spjh/2SgZ4KtDlQ99VkIyk/O6UKm IN2bQ5UYZbYbyOSw+tNhuZa/d9QDJuTbXGnfzREFdzWho53tiENBLoyC3My7RHwe 4A7ee4uXmDliJis/5YnngNt9fefF3IJrfNgmgsT3oiBVW1IGhY0= =48Vi -----END PGP SIGNATURE----- --SCnlG7Tspp7xPBPC--