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 811DDA320B for ; Mon, 21 Oct 2019 15:11:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 59F821BEFA; Mon, 21 Oct 2019 15:11:46 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 5434B1BE97 for ; Mon, 21 Oct 2019 15:11:45 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2019 06:11:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,323,1566889200"; d="scan'208";a="187538862" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga007.jf.intel.com with ESMTP; 21 Oct 2019 06:11:43 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 21 Oct 2019 06:11:43 -0700 Received: from bgsmsx110.gar.corp.intel.com (10.223.4.212) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 21 Oct 2019 06:11:43 -0700 Received: from bgsmsx101.gar.corp.intel.com ([169.254.1.199]) by BGSMSX110.gar.corp.intel.com ([169.254.11.93]) with mapi id 14.03.0439.000; Mon, 21 Oct 2019 18:41:40 +0530 From: "Varghese, Vipin" To: "Richardson, Bruce" CC: "Loftus, Ciara" , 'Stephen Hemminger' , "'dev@dpdk.org'" , "Ye, Xiaolong" , "Laatz, Kevin" , "Yigit, Ferruh" Thread-Topic: [dpdk-dev] [PATCH v2 2/3] net/af_xdp: support pinning of IRQs Thread-Index: AQHVd65xbFLCTXmJzEOr4n4smjb1qadEGKuAgAR3J4CAHBJngIAAifOQ//+oWQCAAF1qkA== Date: Mon, 21 Oct 2019 13:11:39 +0000 Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DCFC2@BGSMSX101.gar.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> In-Reply-To: <20191021130416.GB942@bricha3-MOBL.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDc5NjZjY2UtNzlhNi00MjBhLWExMjgtYmE0NGUzYWI0MmFjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiVkFDWTNpd3YyVVA2MXU4UG5mY3hvUThWN3FlNWJzVks4cVwvU1ZRWnZzZFRCMW5YcnNTN0RFd2N4MXdLU3dKNEMifQ== dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.223.10.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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" 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 scali= ng 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; normall= y `cat > /proc/interrupts` shows IRQ mask to cores. Depending upon FDIR (intel X52= 2 > and X710) this could be core 0 or 'n-1'? > > > Yes, the interrupt pinning default is somewhat dependent on the exact set= up, > but the fact remains that in just about any setup the interrupts for an A= F_XDP > queue are unlikely to end up on the exactly the one core that the user wa= nts > them on. This is what makes this patch so necessary, both from a usabilit= y and > performance point of view. >=20 > In the absense of alternatives, I really think this patch should be merge= d, 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 test= ing 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 r= e- > running apps when testing. Here my understanding, user can not or should not pass DPDK cores for inter= rupt pinning. So should we ask the driver to fetch `rte_eal_configuration` = and ensure the same? >=20 > Regards, > /Bruce