Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp682189pxj; Thu, 27 May 2021 09:15:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwSUqjWKEwAilQyAz0F4e8qSbsy8ChvfSR0Pl6+qWtFEzjBAgy0H7Y9TDdpb0p9gGkrIFkB X-Received: by 2002:a17:906:4f1a:: with SMTP id t26mr4727670eju.280.1622132150360; Thu, 27 May 2021 09:15:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622132150; cv=none; d=google.com; s=arc-20160816; b=aM6pmpz3/7rMXQcEREjnws4Jj8NqKcEhJZX+TvW7M3AOnkX1oLj7/dR3k6pJsu9JB/ g6g1bKHymDCjK4T6i81ArEfCKSLjq33Bryb/31WcpJzl7MTguXw2wjNLEXS3feebA6Yh dvAr9ILYdGmxRzFDLLTIoXKIx6deWVzcQk3UZjEitNFM8Ehuagr2pYbAl2LGsvRG+6Yw yV4pvLEUl5QOVeWnEORe+e+jBzR+UWdXFEOcX/FkB/n3/ynkyyO0qzbCTQbJrmhZYLHv BOiGxPnoTwFBadsPsByWaJj7ZwEnlOMd1wSKagxGV25S7sZ53lASEH3lqmJaJnsuGeoH tqLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ULXKpUDeK1p76UZ59lVMj02cPEcED36GdHXBm75qmHc=; b=qd5xsbTst8j7gcis0gJCQtCYQFOtaioQyP0uuFFPlVFxV/nrn1d+2TPH96bYBrW9N1 nX7VA9Do2WfLS138/JktiR+D+xQX4QC1JZbDQOPf7HbERw8+N27QvPvLFmk1fKuJhhNL FD3jXIUHCYxNw1rqfAJCOI7X4cFt8GJviVnU7rQhDbwjLcnocvjtn2dgScTpf8Ear+9X N97QPkGHkvvF/EogwR3uIw0C6NO3qU4Oe5AMK/esXOofwG0WNeshUYffP4QKLc9mDmsk q5lGy7EdVGmXQODOOL3pV4FhjsruFS8W0anJpnnscHemKOCeGswadKq8/YeSPdORlDbD +06g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Y1hAOBL5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m2si2450466ejk.237.2021.05.27.09.15.07; Thu, 27 May 2021 09:15:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Y1hAOBL5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236206AbhE0NID (ORCPT + 99 others); Thu, 27 May 2021 09:08:03 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:22780 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236007AbhE0NHy (ORCPT ); Thu, 27 May 2021 09:07:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622120780; 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: in-reply-to:in-reply-to:references:references; bh=ULXKpUDeK1p76UZ59lVMj02cPEcED36GdHXBm75qmHc=; b=Y1hAOBL533VZEuaVjLcLfomkbIC2d79ooZx43AG9UbwdKS2q444xeYFCy4myDD+waSfdFJ TlEqkJ/+prVJRbwdDzC3xktBVSKIMQJi982svYvODIlLaoyH5FUHGs77v30aQqvy3rY6GJ NC3TdcvEopIxi040x6/Yc+kkoLkV9WY= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-580-kYtrQdXUP0mEFvecPL4EPQ-1; Thu, 27 May 2021 09:06:19 -0400 X-MC-Unique: kYtrQdXUP0mEFvecPL4EPQ-1 Received: by mail-lj1-f198.google.com with SMTP id v4-20020a2e96040000b02900ce9d1504b5so209961ljh.16 for ; Thu, 27 May 2021 06:06:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ULXKpUDeK1p76UZ59lVMj02cPEcED36GdHXBm75qmHc=; b=K5jntEtMB6iABDnC8CVDwB8e/ZpUSGxcCHqY59QVsinX+GnZRFtGjP212CHSqkHqtP wH9Tq2SgxQ9pTUS5L8wra1Q6h7TTp+BekemhoXpPh45EqtuIi6uPhx18rmcx0pM0pDeE RKabUMxfTpzxOHsow3eQR6yoog6vnqcsnuwimQeDgv7js/JlC6+iKQHsuZYANa+4SXs6 wDNzfFkAbBAGNvw3yqrO3M5WsvCHrwbDlaQn7mS8xsy+9vUV26FQ3LvyCwnz2MSMIfPr zwTk2YHzzp4O5rbNSzvqXMmDveeySiWmTPdYjECopVZmUk2vb4W34e7Oz5Qa31HY76vZ m0tQ== X-Gm-Message-State: AOAM531ig8Gglx83V57bY3+TYAImF0V6yBqy70UdipUSlkLO/qNqShpB XVMCcYC1zdoedqylL2jhspXLOitQt7chDLabGmUfZ8iFG03aG/3XkG3aggvqjkIUl48WDxtP0bZ 0ELuAD957uDiTKMAVsMRkC8ChnH4YE+QLdYLKy711 X-Received: by 2002:a05:651c:511:: with SMTP id o17mr2571074ljp.14.1622120777521; Thu, 27 May 2021 06:06:17 -0700 (PDT) X-Received: by 2002:a05:651c:511:: with SMTP id o17mr2571013ljp.14.1622120777212; Thu, 27 May 2021 06:06:17 -0700 (PDT) MIME-Version: 1.0 References: <20210504092340.00006c61@intel.com> <87pmxpdr32.ffs@nanos.tec.linutronix.de> <87im3gewlu.ffs@nanos.tec.linutronix.de> <87zgwo9u79.ffs@nanos.tec.linutronix.de> <87wnrs9tvp.ffs@nanos.tec.linutronix.de> In-Reply-To: From: Nitesh Lal Date: Thu, 27 May 2021 09:06:04 -0400 Message-ID: Subject: Re: [PATCH] genirq: Provide new interfaces for affinity hints To: Shung-Hsi Yu Cc: Thomas Gleixner , Jesse Brandeburg , Robin Murphy , Marcelo Tosatti , Ingo Molnar , linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, jbrandeb@kernel.org, "frederic@kernel.org" , "juri.lelli@redhat.com" , Alex Belits , "linux-api@vger.kernel.org" , "bhelgaas@google.com" , "linux-pci@vger.kernel.org" , "rostedt@goodmis.org" , "peterz@infradead.org" , "davem@davemloft.net" , "akpm@linux-foundation.org" , "sfr@canb.auug.org.au" , "stephen@networkplumber.org" , "rppt@linux.vnet.ibm.com" , "jinyuqi@huawei.com" , "zhangshaokun@hisilicon.com" , netdev@vger.kernel.org, chris.friesen@windriver.com, Marc Zyngier , Neil Horman , pjwaskiewicz@gmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 27, 2021 at 6:03 AM Shung-Hsi Yu wrote: > > Hi, > > On Fri, May 21, 2021 at 02:03:06PM +0200, Thomas Gleixner wrote: > > The discussion about removing the side effect of irq_set_affinity_hint() of > > actually applying the cpumask (if not NULL) as affinity to the interrupt, > > unearthed a few unpleasantries: > > > > 1) The modular perf drivers rely on the current behaviour for the very > > wrong reasons. > > > > 2) While none of the other drivers prevents user space from changing > > the affinity, a cursorily inspection shows that there are at least > > expectations in some drivers. > > > > #1 needs to be cleaned up anyway, so that's not a problem > > > > #2 might result in subtle regressions especially when irqbalanced (which > > nowadays ignores the affinity hint) is disabled. > > > > Provide new interfaces: > > > > irq_update_affinity_hint() - Only sets the affinity hint pointer > > irq_apply_affinity_hint() - Set the pointer and apply the affinity to > > the interrupt > > > > Make irq_set_affinity_hint() a wrapper around irq_apply_affinity_hint() and > > document it to be phased out. > > Is there recommended way to retrieve the CPU number that the interrupt has > affinity? > > Previously a driver (I'm looking at drivers/net/ethernet/amazon/ena) that > uses irq_set_affinity_hint() to spread out IRQ knows the corresponding CPU > number since they're using their own spreading scheme. Now, phasing out > irq_set_affinity_hint(), and thus relying on request_irq() to spread the > load instead, there don't seem to be a easy way to get the CPU number. > For drivers that don't want to rely on request_irq for spreading and want to force their own affinity mask can use irq_set_affinity() which is an exported interface now [1] and clearly indicates the purpose of the usage. As Thomas suggested we are still keeping irq_set_affinity_hint() as a wrapper until we make appropriate changes in individual drivers that use this API for different reasons. Please feel free to send out a patch for this driver once the changes are merged. [1] https://lkml.org/lkml/2021/5/18/271 -- Thanks Nitesh