From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F2CD3A2EFC for ; Mon, 14 Oct 2019 16:43:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 232D51C0CE; Mon, 14 Oct 2019 16:43:17 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 08B551C0CC for ; Mon, 14 Oct 2019 16:43:14 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2019 07:43:13 -0700 X-IronPort-AV: E=Sophos;i="5.67,296,1566889200"; d="scan'208";a="207225373" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.95]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2019 07:43:11 -0700 Date: Mon, 14 Oct 2019 15:43:08 +0100 From: Bruce Richardson To: "Loftus, Ciara" Cc: Stephen Hemminger , "dev@dpdk.org" , "Ye, Xiaolong" , "Laatz, Kevin" , ferruh.yigit@intel.com, arybchenko@solarflare.com Message-ID: <20191014144308.GA1394@bricha3-MOBL.ger.corp.intel.com> References: <20190930164205.19419-1-ciara.loftus@intel.com> <20190930164205.19419-3-ciara.loftus@intel.com> <20190930101137.4919f93e@hermes.lan> <74F120C019F4A64C9B78E802F6AD4CC279226C6C@IRSMSX106.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74F120C019F4A64C9B78E802F6AD4CC279226C6C@IRSMSX106.ger.corp.intel.com> User-Agent: Mutt/1.12.1 (2019-06-15) Subject: Re: [dpdk-dev] [PATCH v2 2/3] net/af_xdp: support pinning of IRQs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Oct 03, 2019 at 02:23:07PM +0100, Loftus, Ciara wrote: > > > > -----Original Message----- From: Stephen Hemminger > > Sent: Monday 30 September 2019 18:12 To: > > Loftus, Ciara Cc: dev@dpdk.org; Ye, Xiaolong > > ; Laatz, Kevin ; > > Richardson, Bruce Subject: Re: [dpdk-dev] > > [PATCH v2 2/3] net/af_xdp: support pinning of IRQs > > > > On Mon, 30 Sep 2019 16:42:04 +0000 Ciara Loftus > > wrote: > > > > > +/* drivers supported for the queue_irq option */ +enum > > > supported_drivers { + I40E_DRIVER, + IXGBE_DRIVER, + > > > MLX5_DRIVER, + NUM_DRIVERS +}; > > > > Anything device specific like this raises a red flag to me. > > > > This regex etc, seems like a huge hack. Is there a better way using > > irqbalance and smp_affinity in kernel drivers? > > > > NACK > > Hi Stephen, > > Thanks for looking at the patch. I understand your concern however > unfortunately I haven't been able to identify a way to achieve the > desired outcome by using your suggestions of irqbalance and smp_affinity. > Did you have something specific in mind or are aware of any generic way > of retrieving interrupt numbers for NICs regardless of vendor or range? > > I think this feature is really important for the usability of this PMD. > Without it, to configure the IRQs the user has to open up > /proc/interrupts, trawl through it and identify the correct IRQ number > for their given NIC and qid (the format for which is unlikely to be known > off-hand), and manually pin them by writing the appropriate values in the > appropriate format to the appropriate file - prone to error if not > automated IMO. If the user fails to set the affinity it's probably fine > for a single pmd, however with multiple pmds all irqs will by default > land on core 0 and lead to terrible performance. > > It should be possible to rework the code to remove the regexes and use a > direct string compare. Would that make the solution more palatable? > Hi Ciara, Stephen, is there any way forward on this patch? >From my experience with using AF_XDP the pinning of interrupts is both necessary for performance and sadly rather awkward to implement in practice. If we can't find a better way to do this, I think merging this patch is the best thing to do. It may be a bit messy, but the overall user experience should be far improved over not having it. Regards, /Bruce