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 31A27352932; Thu, 13 Nov 2025 13:25:36 +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=1763040336; cv=none; b=LErYumUSlPiUknwiIQXSW9/XR2ldbi6sfzr/VtTyFuXd/eiYQQTSNpkcI+q1VojQD3f5HrePmhP0k5yfKMMtN3X5IXy3I6QlDB2gE5fCkbbzi0UPzLC3CrwnssHG63LJ4aQA+Rb5rRUitFPk7EdYjCSU/jt0PoncaWOC3y/q47s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763040336; c=relaxed/simple; bh=2beZImer8eWKIWcDAocCGxfxykTRh4iaBe3x/wgdk4U=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ZGCQLZcC4ASdIeaU6alr2NtkZrd1Wnd9SfTTzsg/txTI/Ltfa+i7+sc2dpP+efSu/Jdr4OhC1uw/VH2BNv1x792vKi8WuOK978GK4Ae5RhwWjxlJLnbJEZuZ8dweM/8SEzqhDyL11EZ03wrmKsO6lqHSwVxhUXT2EkK0gsOvoHc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RABtzDeV; 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="RABtzDeV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0096BC2BC87; Thu, 13 Nov 2025 13:25:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763040336; bh=2beZImer8eWKIWcDAocCGxfxykTRh4iaBe3x/wgdk4U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RABtzDeVbXRDOvl93LROn+Mckrp/mKLXEXnPz99QkOkX+h1lng7C5tMyKn0xde662 w5Mwl261mDV+jRn9c8RysceJjqrN558vI6j9Soco3hRKwV4OvPZMEh9/GqerBXBmob w9KOc6c4m/6tcsWUm4SK7Wi0E4+S/vFCBMsQz9DJSNO4+ayRbHXkUMkI3ZehJmzQcT yBQIa0W3Xdi2CuO3HICKIvH+p77EHLhG9cFWAQfKjTXASoA2L/R2wo1J8YneZ+sXIR mFQt3insYK4LypCl0Mwwestyw6XGbJjR22Kkxj0tbbRnoTsSmANRpAx3PFnYY88iIp eXFCQPzVaDpYA== 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 1vJXKP-00000004snh-1stV; Thu, 13 Nov 2025 13:25:33 +0000 Date: Thu, 13 Nov 2025 13:25:33 +0000 Message-ID: <86o6p6t67m.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: <20251112192408.3646835-2-lrizzo@google.com> References: <20251112192408.3646835-1-lrizzo@google.com> <20251112192408.3646835-2-lrizzo@google.com> 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=US-ASCII 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 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? [...] > +Platform Wide software interrupt moderation is a variant of moderation > +that adjusts the delay based on platform-wide metrics, instead of > +considering each source separately. It then uses hrtimers to implement > +adaptive, per-CPU moderation in software, without requiring any specific > +hardware support other than Pending Bit Array, a standard feature > +of MSI-X. > + > +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. > + > +* **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? M. -- Without deviation from the norm, progress is not possible.