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 D6F5CA320B for ; Mon, 21 Oct 2019 14:52:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D0A6E1BF1D; Mon, 21 Oct 2019 14:52:34 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 077B437B7 for ; Mon, 21 Oct 2019 14:52:32 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2019 05:52:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,323,1566889200"; d="scan'208";a="196803042" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga007.fm.intel.com with ESMTP; 21 Oct 2019 05:52:32 -0700 Received: from fmsmsx125.amr.corp.intel.com (10.18.125.40) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 21 Oct 2019 05:52:31 -0700 Received: from bgsmsx151.gar.corp.intel.com (10.224.48.42) by FMSMSX125.amr.corp.intel.com (10.18.125.40) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 21 Oct 2019 05:52:31 -0700 Received: from bgsmsx101.gar.corp.intel.com ([169.254.1.199]) by BGSMSX151.gar.corp.intel.com ([169.254.3.95]) with mapi id 14.03.0439.000; Mon, 21 Oct 2019 18:22:28 +0530 From: "Varghese, Vipin" To: "Loftus, Ciara" , 'Stephen Hemminger' CC: "'dev@dpdk.org'" , "Ye, Xiaolong" , "Laatz, Kevin" , "Richardson, Bruce" , "Yigit, Ferruh" Thread-Topic: [dpdk-dev] [PATCH v2 2/3] net/af_xdp: support pinning of IRQs Thread-Index: AQHVd65xbFLCTXmJzEOr4n4smjb1qadEGKuAgAR3J4CAHBJngIAAifOQ Date: Mon, 21 Oct 2019 12:52:27 +0000 Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D3DCF94@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> In-Reply-To: <74F120C019F4A64C9B78E802F6AD4CC27924737D@IRSMSX106.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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2Y4N2ExY2YtNjgwZC00ZGVlLTk3MTAtZjY1ZTEyN2E1ZWZkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidWhtYWhBQklXaTBUdDdyTmRRSXh0dnVVZG5SeTZpNGVoYUg0cWdpTEcwc2g4QWpyZllsa3FQekh0XC9WTzNzN1AifQ== 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 Ciara, snipped >=20 > ifaces no pinning pinning > 1 9059100 9171612 > 2 9261635 18376552 > 3 9332804 27696702 >=20 > For the no-pinning case, all IRQs are landing on the default core 0, whic= h > results in very poor scaling versus the pinned case where scaling is line= ar. 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' i= s done for all expect core 0?` If the cores are not isolated and no interrupts are redirected; normally `c= at /proc/interrupts` shows IRQ mask to cores. Depending upon FDIR (intel X5= 22 and X710) this could be core 0 or 'n-1'? >=20 > Thanks, > Ciara >=20 > > > > 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? > > > > Let me know what you think. > > > > Thanks, > > Ciara