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 2F772A320B for ; Mon, 21 Oct 2019 15:17:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5BEAE1BF07; Mon, 21 Oct 2019 15:17:26 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 3114B1BEFA for ; Mon, 21 Oct 2019 15:17:23 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2019 06:17:23 -0700 X-IronPort-AV: E=Sophos;i="5.67,323,1566889200"; d="scan'208";a="191109080" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.95]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2019 06:17:21 -0700 Date: Mon, 21 Oct 2019 14:17:18 +0100 From: Bruce Richardson To: "Varghese, Vipin" Cc: "Loftus, Ciara" , 'Stephen Hemminger' , "'dev@dpdk.org'" , "Ye, Xiaolong" , "Laatz, Kevin" , "Yigit, Ferruh" Message-ID: <20191021131718.GD942@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> <74F120C019F4A64C9B78E802F6AD4CC27924737D@IRSMSX106.ger.corp.intel.com> <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DCF94@BGSMSX101.gar.corp.intel.com> <20191021130416.GB942@bricha3-MOBL.ger.corp.intel.com> <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DCFC2@BGSMSX101.gar.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DCFC2@BGSMSX101.gar.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 Mon, Oct 21, 2019 at 02:11:39PM +0100, Varghese, Vipin wrote: > Hi Bruce, > > snipped > > > > > > > > For the no-pinning case, all IRQs are landing on the default core 0, > > > > which results in very poor scaling versus the pinned case where scaling is > > linear. > > > > > > Thanks for the information, but a question here `Is the reason for > > > landing all IRQ on core '0' is because the Kernel CMD line 'isol or no > > > interupts' is done for all expect core 0?` > > > > > > If the cores are not isolated and no interrupts are redirected; normally `cat > > /proc/interrupts` shows IRQ mask to cores. Depending upon FDIR (intel X522 > > and X710) this could be core 0 or 'n-1'? > > > > > Yes, the interrupt pinning default is somewhat dependent on the exact setup, > > but the fact remains that in just about any setup the interrupts for an AF_XDP > > queue are unlikely to end up on the exactly the one core that the user wants > > them on. This is what makes this patch so necessary, both from a usability and > > performance point of view. > > > > In the absense of alternatives, I really think this patch should be merged, since > > with more than one point the difference between having correctly or > > incorrectly pinned interrupts is huge. I'd also point out that in my testing the > > interrupts need to be pinned each and every time an app is run - it's not a set > > once and forget thing. > Yes, I agree with you as in my testing with XDP and FDIR we had to do this in each test run. > > This ability to have the driver pin the interrupts for the > > user would be a big timesaver for developers too, who may be constantly re- > > running apps when testing. > Here my understanding, user can not or should not pass DPDK cores for interrupt pinning. So should we ask the driver to fetch `rte_eal_configuration` and ensure the same? > Actually I disagree. I think the user should pass the cores for interrupt pinning, because unlike other PMDs it is perfectly valid to have the interrupts pinned to dedicated cores separate from those used by DPDK. Or taking another example, suppose the app takes 8 cores in the coremask, but only one of those cores is to be used for I/O, what cores should the driver pin the interrupts to? It probably should be the same core used for I/O, but the driver can't know which cores will be for that, or alternatively the user might want to use AF_XDP split across two cores, in which case any core on the system might be the intended one for interrupts. Regards, /Bruce