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=OW1XBEzl; 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 6133A5A004C for ; Thu, 05 Sep 2024 10:32:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725525165; 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=e4UvY4BbWdvPUPB6Ye9RwplmFbXnBhRfW59irLu1kNU=; b=OW1XBEzlN5szlPZdEC5DaF4t3m/I/pkDE0h/LStjwr3Td1wDvQfwN4UHUVFseADGnSMg4H A61dhrh8qdbbxBrYMTK0qb6P/s95gOE6TtbbPb3TSjqNj7IKoHBcK5xTRna4h+GsaO7Ewq +4ZVLtFrxfC6HZILOZ8/PmvLAatJWcQ= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-10--9ARFeFSMLy2sVK4rfPyYg-1; Thu, 05 Sep 2024 04:32:43 -0400 X-MC-Unique: -9ARFeFSMLy2sVK4rfPyYg-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-42bb68e16b0so4845775e9.1 for ; Thu, 05 Sep 2024 01:32:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725525162; x=1726129962; 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=e4UvY4BbWdvPUPB6Ye9RwplmFbXnBhRfW59irLu1kNU=; b=Ad39fOTHa+gm2O1XF60TOroyUN0aSohEikD7qzRfLv9ZTzoJzm0eCRwi1mNHxJjtUm m5M6d0VDR8SttjJTMkXVggl8CRREPw0JRGJf7deunhbnPGo8u+c3pGuDQi9eu5rVMira 87BPac2uK7BONG87a7cqxplnoE6wpvSSnxXGyWs2TKy47wAnm3q/Eo2J1xjzUzzezZZG JrAaqUOOYo+YUCaUffZNRmwTuFAtx99/I6tQiTFQi3+lmVMDBmBQ5XfBRKpUomPxeHKV Hlph6tmuIbKbIOUOxlI+Foq8xvkDaXCLJeVVea9zorVkkVM+14Cpi0CpB5O5g777dfF3 drOA== X-Gm-Message-State: AOJu0YxNodarrGyppBNmMFg6xQNV0mXTI4OW7v7X9zRGHSOc6wDoAZOY V2lP+eMcLf/KLvWpud6opvufj0azX5VMG800b0dfg540dhzfeUSbnidBOsx0CNmyrsTK3HLCp3C E4A6USFJgoMPqXuxSQj5ZQzBqpPYCqyq26ONfFwUSm4acWikG/WTr3WFpaQ== X-Received: by 2002:a05:600c:3c90:b0:426:5e1c:1ac2 with SMTP id 5b1f17b1804b1-42c9a366417mr13336625e9.8.1725525161557; Thu, 05 Sep 2024 01:32:41 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFDDtXpWU5Ve//0LK3kSST1VRXEPZd0bejVJavkAVuYAfzFVIpHtxBi6OZ8t5uri9LX0PVHxA== X-Received: by 2002:a05:600c:3c90:b0:426:5e1c:1ac2 with SMTP id 5b1f17b1804b1-42c9a366417mr13336395e9.8.1725525161051; Thu, 05 Sep 2024 01:32:41 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42bb6deb303sm229961385e9.9.2024.09.05.01.32.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Sep 2024 01:32:40 -0700 (PDT) Date: Thu, 5 Sep 2024 10:32:38 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 0/6] RFC: Clean up tap-side event handling Message-ID: <20240905103238.69431d8f@elisabeth> In-Reply-To: References: <20240903120235.1688429-1-david@gibson.dropbear.id.au> <20240903212554.036da194@elisabeth> <20240904191922.146bb53e@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: 53JRCMSE5LCGZIECU7LUOFDNGVCQBFJA X-Message-ID-Hash: 53JRCMSE5LCGZIECU7LUOFDNGVCQBFJA 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 Thu, 5 Sep 2024 10:35:14 +1000 David Gibson wrote: > 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: > > > > > 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 > > 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. > > > > 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? Right now, we have a condition where we fail to handle EPOLLRDHUP before an outbound connection is established, see https://github.com/containers/podman/issues/23686#issuecomment-233023742, and we end up in a tight event processing loop. I guess what we're missing in tcp_sock_handler() is clear (we should orderly close the connection), but the tight loop didn't happen on 2024_06_24.1ee2eca (I'm bisecting right now) and we don't know why it didn't. If we set EPOLLET, we won't see that anymore, because the EPOLLRDHUP event is reported just once, but that doesn't mean we solved this. -- Stefano