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 D583B2040A8 for ; Mon, 2 Dec 2024 14:26:40 +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=1733149600; cv=none; b=BRpGf8CxyPQekFoDubs4W5gshhlXMeWrF/DauTpNIBQuXruMr4vT/yBglERIRd0fgEY/zJbpy6AlLQ8noEogcHTBUhY2+xdPAGg6YdUt/ApgXFqdHcnbkbbEVHUQEep1jrVmPQnn1uTmlEe/Pn9KPZEUSCdcNTGLcuLyvoHc3TU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733149600; c=relaxed/simple; bh=AmudBNYCJmeJXtRs6H3kdNst2ZYo2l226+VYOM8fXGY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IUxQN9m4zIinu7NLz86Lm2SPFjr5Lhe3SZK+BgdMSsGkzE86uz1297Vo9mjP9KIexnr2CAEcJzepCeMQZDQ91sFaDstJ0T6y5raZVpniJGok/egjm45QjVHzgJ/qoq77FuKhdmDEvWjFQO0Q0NhsGc4Is3Q59vzSmP3WYeEKto0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G//t/2sv; 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="G//t/2sv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8BA66C4CED6; Mon, 2 Dec 2024 14:26:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733149600; bh=AmudBNYCJmeJXtRs6H3kdNst2ZYo2l226+VYOM8fXGY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=G//t/2svnDaX5LCybS8wzt8zWQKKB0wN68CiNYSI9Nlkwgz6vPqviFIDXb3gr68El HkT6vPuKGy379ZlG9t8E7SWIuZcdyty/1PHQ4SXjai0N1VQgzm2DuYx/VWw0Eu2Cez HR6/5cAA+t/iAd7uonbB16fXbsdvjBmJ4P71VaCzSzw1dXd/PKzy4k7VbGI3h7qRRX 55pATJxv59xmbKWMLnabVbq44SieWsY16TOR3Rfv9yDIDg4ZOBeUN2EoCo7mRuM1mC J7BN667yCC6faFfyYr63uFFe2/w1Br34ighiyz6FD+8+7+W0wBn8NaCCSJXMVwIxd6 XIjQgj6SDk96Q== Date: Mon, 2 Dec 2024 06:26:39 -0800 From: Jakub Kicinski To: Ahmed Zaki Cc: , Subject: Re: [PATCH iwl-net 1/2] idpf: preserve IRQ affinity settings across resets Message-ID: <20241202062639.30ddac57@kernel.org> In-Reply-To: <96df3bc7-85ab-4e21-a26d-3785874454a8@intel.com> References: <20241109001206.213581-1-ahmed.zaki@intel.com> <20241109001206.213581-2-ahmed.zaki@intel.com> <20241111185334.447a5253@kernel.org> <96df3bc7-85ab-4e21-a26d-3785874454a8@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 2 Dec 2024 06:03:45 -0700 Ahmed Zaki wrote: > On 2024-11-11 7:53 p.m., Jakub Kicinski wrote: > > On Fri, 8 Nov 2024 17:12:05 -0700 Ahmed Zaki wrote: > >> From: Sudheer Mogilappagari > >> > >> Currently the IRQ affinity settings are getting lost when interface > >> goes through a soft reset (due to MTU configuration, changing number > >> of queues etc). Use irq_set_affinity_notifier() callbacks to keep > >> the IRQ affinity info in sync between driver and kernel. > > > > Could you try doing this in the core? Store the mask in napi_struct > > if it has IRQ associated with it? > > > > Barely any drivers get this right. > > The napi structs are allocated/freed with open/close ndos. I don't think > we should expect the user to re-set CPU affinity after link down/up. The napi_config struct is persistent.