From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=VvQWYSAx; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 249975A004E for ; Wed, 04 Sep 2024 19:19:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725470372; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jDU8SYi8DBY2ObzDj/wI9lZZUzUiLbm6MjZr1TWlZRo=; b=VvQWYSAx+Uig4ATrpQjTkd/yuHCBg+UuIjwjQ18BnGzQz0sJKEx0FrudVfTMae/tSxOPBJ ErjrKDjY5YFO/zLNr6L+HfhU+OPFr40luWFmtQ5ROCXjswCBciT/dMxgPq6d3OYGZBwccJ EXO7GMbqmHODtgauD167C6EyhdpmCrg= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-136-uPSQKh1-M0SIJJutLeHDFQ-1; Wed, 04 Sep 2024 13:19:30 -0400 X-MC-Unique: uPSQKh1-M0SIJJutLeHDFQ-1 Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2052d07ff07so51727355ad.2 for ; Wed, 04 Sep 2024 10:19:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725470368; x=1726075168; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jDU8SYi8DBY2ObzDj/wI9lZZUzUiLbm6MjZr1TWlZRo=; b=UNECPShj8XyX2T3SNShlcnDH7f0OG9dZhsK4uZSWbx8ASTJgmmMOn5RKEnZS4YuL9k i8RcjPbLcIcszPLfaJ3OxKG8paRE8cT/szZa1oeHf57nGHdv6qNvMdn+PRBTutYy63FZ +VWgcaPGWj7IeGjcYGjE7a/7Y+JQ4dR/WpC8PG+EKK5rgiCLbXAkyBVDr3wH5/MaJQ19 zP1oVafk0axZ2SixWGVDbH6PQmWf/eyVBY3pNKkdSTJjGNsGD50UNZfmtgQ8ZN/dktZZ RsLECYV3Qh6LhzH5H3mDCJRvHyyKdUJwo8oUWtaN1dC0SSnXfIt31GW8wihBzLNOIyzm GOog== X-Gm-Message-State: AOJu0YyatbN9QsXRPj9I2eiqtcegwDHDqP4VGSvICXGT3JgTiYYo39W8 f79AyG/HlLgU8lZUEIXa/JEtruvjBAxI0om4um/4eX9arZ2eMgYTswIMDJcTC7zJdIexMuyqD08 qQR3cU/AU+NrwCLQZq6tLDm6M/hVpBUKGrxzpXQTB++1JI2sQnwYj/pWKEw== X-Received: by 2002:a17:902:f601:b0:1fb:2bed:6418 with SMTP id d9443c01a7336-2054ca754e7mr155407865ad.57.1725470368492; Wed, 04 Sep 2024 10:19:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFYK2Fhf0bNOTH55JsU1YUsSdqdSByYE1xnUUHU0zJbrldvGCEaFD24jgB3XeZKHrnbIysdug== X-Received: by 2002:a17:902:f601:b0:1fb:2bed:6418 with SMTP id d9443c01a7336-2054ca754e7mr155407595ad.57.1725470368044; Wed, 04 Sep 2024 10:19:28 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-206aea3a30fsm15841285ad.127.2024.09.04.10.19.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2024 10:19:26 -0700 (PDT) Date: Wed, 4 Sep 2024 19:19:22 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 0/6] RFC: Clean up tap-side event handling Message-ID: <20240904191922.146bb53e@elisabeth> In-Reply-To: References: <20240903120235.1688429-1-david@gibson.dropbear.id.au> <20240903212554.036da194@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 74LTNJTTGHYACVDZOZ6Z52HKHMRPR53D X-Message-ID-Hash: 74LTNJTTGHYACVDZOZ6Z52HKHMRPR53D X-MailFrom: sbrivio@redhat.com 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: On Wed, 4 Sep 2024 13:17:53 +1000 David Gibson wrote: > 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: > > > > > 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. > > > > 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. > > > > 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=94. 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 don't see at the moment anything indicating TCP issues other than the one you addressed with your tentative debug patch at: https://passt.top/passt/commit/?h=podman23686&id=026fb71d1dde60135d95741552906fd5320384bc Given that, with that patch, we had at least another report of event storms, this time on UDP, that is, the one from: https://github.com/containers/podman/issues/23686#issuecomment-2324945010 I shared this other one on top: https://passt.top/passt/commit/?h=podman23686&id=0c6c20dee5c24bd324834a99f409ad43c50812ae > 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. Sure, it's going to be simpler and more robust, but on the other hand we wouldn't notice these kind of issues. > > 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. 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). > 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. I understand that they shouldn't alter it, but if we missed something subtle and they actually do, they'll make bisection more complicated. 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)? -- Stefano