From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta-64-226.siemens.flowmailer.net (mta-64-226.siemens.flowmailer.net [185.136.64.226]) (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 3EFC535E926 for ; Fri, 21 Aug 2026 16:47:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.136.64.226 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787330865; cv=none; b=ltw2OQ5mTu3SQ44ZFYHAM1AcrQkLGtm2TLTg7a3ocabJQLn8r/9+i4pI+UVScWnEMFy6E7tlj9U9f+HCcoBH52SiUedyW553DX4DgSi61voS6rF2KRCr9rjhhDTH5R0pgRIDUOPZuYXiqDQ2vmu1HlEFU2WhxtvLj5/V8DKWkPI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787330865; c=relaxed/simple; bh=6hWEk52ybKytfOaNhLZYJpexQsQeY7dx+xyw91Pdc1U=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=ALxjmgNieKBeB8JvoY1uuRIeSJMO3DDcdk8KYOSwBakLaPnSUOFYHDAiSpeWyybk3+4jKIBnepMYPYJbdlaDzgdsWArNCE3uKf9HGogtfHfmHIEM2B8ZYKBiuDOrZCfAfETngwhqoT2O8kQaOa0KqczuRTodjIDpAKjjvK/za0M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=siemens.com; spf=pass smtp.mailfrom=rts-flowmailer.siemens.com; dkim=pass (2048-bit key) header.d=siemens.com header.i=florian.bezdeka@siemens.com header.b=TBwnOHPP; arc=none smtp.client-ip=185.136.64.226 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=siemens.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rts-flowmailer.siemens.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=siemens.com header.i=florian.bezdeka@siemens.com header.b="TBwnOHPP" Received: by mta-64-226.siemens.flowmailer.net with ESMTPSA id 2026082116473791bed685a200020734 for ; Fri, 21 Aug 2026 18:47:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm2; d=siemens.com; i=florian.bezdeka@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Cc:References:In-Reply-To; bh=yAUIv3QVPUxeZj+2jjQt2DSdbC2rNzRDTLXd8pgK7IU=; b=TBwnOHPPmjRt/JJJmjAiFj3ThMLkDziWdpLctnwdO+1UQAOFwoxw3/tkqalYvIdHHJQ8AT aVz42iTgxiI3vccu4INGZGXK2lFvmYyB0RLzrmaiPlm6h6uHrjBmi6NPuO50z/w4gYMBYa3n q4N8k1dHw7zStWfaztBAoDzvbYBLUcSGHDv50xi0rhJrkAadwWhGoX72zFrh8c6U6VKc3kur rKCiJupR9LV9FBoqDeJk0+E9s2oHpHNGrRy7uMg+N5VIIo81OrGibQOke/9d3R6X2l0jgnu1 dszOSZsmJJFhQ3VrrIRrtpcf8/kNstKWOHRbSrwuR0vIAtlc8Vjpp8XQ==; Message-ID: Subject: Re: [PATCH RFC 0/3] genirq: Allow drivers to respect userspace IRQ affinities From: Florian Bezdeka To: Andrew Lunn Cc: Maxime Chevallier , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Alexandre Torgue , Yury Norov , Rasmus Villemoes , Andrew Morton , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , Thomas Gleixner , Jan Kiszka , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Date: Fri, 21 Aug 2026 18:47:36 +0200 In-Reply-To: References: <20260819-flo-net-7-2-make-stmmac-default-affinity-aware-v1-0-3f79a99cadaf@siemens.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-68982:519-21489:flowmailer Hi Andrew, On Thu, 2026-08-20 at 01:54 +0200, Andrew Lunn wrote: > > That raises the question why request_irq() is called on "link up" time, > > while the low level vector allocation takes place during device probing= . >=20 > If the interface is admin down, the hardware should not be generating > any interrupts. So there is no need to request them. >=20 > > At least that seems to be the common pattern. Can someone tell me why > > this is done this way? Shouldn't we call request_irq() at the same time= ? >=20 > If you want to change anything, move the low level vector allocation > into open(). But you need to be careful of EPROBE_DEFER. If the > interrupt controller has not loaded yet, i _guess_ the low level > vector allocation will return EPROBE_DEFER, and the MAC driver will > try to probe again later. If you get EPROBE_DEFER in open(), there is > nothing you can do about it. >=20 > Andrew Moving (=3Ddelaying) the vector allocation into open() would not help here. The /proc/irq/ interface is populated on request_irq(), normally done inside open() as well. Up to this point userspace is not able to set any affinities. This is one of the shortcomings mentioned in the cover letter. Once /proc/irq/ appears, it might already be too late for a proper affinity setting, the IRQ might have fired already. In addition there is no notification mechanism that informs userspace about newly requested IRQs. It's more of the opposite that might help: Moving request_irq() into the probe() phase. I'm wondering why the pattern is vector alloc =3D> probe() request irq =3D> open() Seems that we would not "waste" too much resources when we move request_irq() calls into probe() as well. But as always: I might miss something. Florian