From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DD1112D661C; Thu, 13 Nov 2025 14:42:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763044949; cv=none; b=Ach6JD4RpmRh8OPhlz4y11lqtNGFrmHDFmtM5CENf6CyLlMUXDIRHZeHs9+EnEYfNa3U1VIf6Pm7ebZkzBCQw5yIi4gtArUQUHsKPlPVbKlE5WtpbVFt7I1TB5O7MPZYc0yHAujsj5as+V1+/0gGyThMMlT+1KBc12uLdVPaoqQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763044949; c=relaxed/simple; bh=dTOdH5XXahBmpE3YhOi/ArZkYgYWK5rGtHBHSoKtRnA=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=S+hbF4vEjSQ+8pv/iLN6S9iUjRs7ASB6Fzt6OrSy2VsaSYts42jPiYFgh8m92lbO03/Y20zHAaQUe52THCYOwnrlpIWEWNUAk42SfGOQojQsv3e2frk2lufJzmM9bbNEyjSc7Y/WGmo+fX3DLweap+17QXQolfq5LZLBIQM1CiM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BUFMEC43; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BUFMEC43" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67599C116D0; Thu, 13 Nov 2025 14:42:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763044948; bh=dTOdH5XXahBmpE3YhOi/ArZkYgYWK5rGtHBHSoKtRnA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BUFMEC43P+MjRbP7up2539GgXoU13bo2rMh1uVfKvuJHKQEH7voJMpJrpi1EJWaCV M3SyYJfXW7niBTieRafYfS+PJBUjz+tIhf+GLKNwxyJb5x3Ec77uThIN70hBIRh82e Dvy1oSSEDjCxt4mn3DX23bX69IusDYtu4IduDiR9jrXtZ9HRpuH7386Y9Bqi76w76n 8fQM+zXBALAWXOCmIdPG+sJXKtB96PjtxwR7gmGrhEE16AuypB3KyX79j2Nsq5U+QP OZjoJsTems7T60JqVY5NOJBpKQlpZ/adk0wVUyPHQnhSGa5T1hzl9qZz/b8GjUgfZM 4O/xghz/TIvGQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vJYWo-00000004u5n-0RcC; Thu, 13 Nov 2025 14:42:26 +0000 Date: Thu, 13 Nov 2025 14:42:25 +0000 Message-ID: <86jyzut2ni.wl-maz@kernel.org> From: Marc Zyngier To: Luigi Rizzo Cc: Thomas Gleixner , Luigi Rizzo , Paolo Abeni , Andrew Morton , Sean Christopherson , Jacob Pan , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Bjorn Helgaas , Willem de Bruijn Subject: Re: [PATCH 1/6] genirq: platform wide interrupt moderation: Documentation, Kconfig, irq_desc In-Reply-To: References: <20251112192408.3646835-1-lrizzo@google.com> <20251112192408.3646835-2-lrizzo@google.com> <86o6p6t67m.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: lrizzo@google.com, tglx@linutronix.de, rizzo.unipi@gmail.com, pabeni@redhat.com, akpm@linux-foundation.org, seanjc@google.com, jacob.jun.pan@linux.intel.com, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, bhelgaas@google.com, willemb@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 13 Nov 2025 13:33:51 +0000, Luigi Rizzo wrote: >=20 > On Thu, Nov 13, 2025 at 2:25=E2=80=AFPM Marc Zyngier wro= te: > > > > On Wed, 12 Nov 2025 19:24:03 +0000, > > Luigi Rizzo wrote: > > > > [...] > > > > > The system does not rely on any special hardware feature except from > > > MSI-X Pending Bit Array (PBA), a mandatory component of MSI-X > > > > Is this stuff PCI specific? if so, Why? What is the actual dependency > > on PBA? It is it just that you are relying on the ability to mask > > interrupts without losing them, something that is pretty much a given > > on any architecture? >=20 > You are right, I was overly restrictive. I only need what you say, > will replace the text accordingly. >=20 > > > > [...] > > > +To understand the motivation for this feature, we start with some > > > +background on interrupt moderation. > > > > This reads like marketing blurb. This is an API documentation, and it > > shouldn't be a description of your motivations for building it the way > > you did. I'd suggest you stick to the API, and keep the motivations > > for the cover letter. >=20 > ok will remove it. > Sorry if it reads like marketing, that is very very far from my intention= s. > I just wanted to give background information in a way that is easy > to access from the source tree. Background information is only valid at a given point in time, for a particular configuration, and rarely translate into something that spans architectures and implementation in a universal way. For a start, the quoted figures for interrupt rates are pretty much irrelevant -- think of reading this in 10 years... The descriptions are also massively x86-specific. That's probably OK for the stuff you care about, but I'd certainly would want things to be a bit more abstract and applicable to all architectures. > > > +* **Interrupt** is a mechanism to **notify** the CPU of **events** > > > + that should be handled by software, for example, **completions** > > > + of I/O requests (network tx/rx, disk read/writes...). > > > > That's only half of the truth, as this description only applies to > > *edge* interrupts. Level interrupts report a change in *state*, not an > > event. > > > > How do you plan to deal with interrupt moderation for level > > interrupts? >=20 > I don't. This is restricted to edge interrupts. I also note that since you explicitly check for handle_edge_irq() in set_moderation_mode(), this will not work on anything GIC related, or any other architecture that uses the fasteoi flows. I really wonder why you are not looking at the actual trigger mode instead... Until you fix it, please refrain from touching the GICv3 code, and make sure this is solely enabled on x86 -- it clearly wasn't tested on anything else. Thanks, M. --=20 Without deviation from the norm, progress is not possible.