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 0FACBA320B for ; Mon, 21 Oct 2019 12:04:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E0A971BE8E; Mon, 21 Oct 2019 12:04:20 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 0BE288F96 for ; Mon, 21 Oct 2019 12:04:18 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2019 03:04:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,323,1566889200"; d="scan'208";a="200385638" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga003.jf.intel.com with ESMTP; 21 Oct 2019 03:04:16 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.185]) by irsmsx105.ger.corp.intel.com ([169.254.7.210]) with mapi id 14.03.0439.000; Mon, 21 Oct 2019 11:04:16 +0100 From: "Loftus, Ciara" To: '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: AQHVd65WqjjxpWtTx0OIQh/+EUtsHadEZBuAgASHj+CAHBAUIA== Date: Mon, 21 Oct 2019 10:04:15 +0000 Message-ID: <74F120C019F4A64C9B78E802F6AD4CC27924737D@IRSMSX106.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> In-Reply-To: <74F120C019F4A64C9B78E802F6AD4CC279226C6C@IRSMSX106.ger.corp.intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2Y4N2ExY2YtNjgwZC00ZGVlLTk3MTAtZjY1ZTEyN2E1ZWZkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidWhtYWhBQklXaTBUdDdyTmRRSXh0dnVVZG5SeTZpNGVoYUg0cWdpTEcwc2g4QWpyZllsa3FQekh0XC9WTzNzN1AifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.180] 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" > > 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 >=20 > Hi Stephen, >=20 > Thanks for looking at the patch. I understand your concern however > unfortunately I haven't been able to identify a way to achieve the desire= d > 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 retrie= ving > interrupt numbers for NICs regardless of vendor or range? >=20 > I think this feature is really important for the usability of this PMD. W= ithout it, > to configure the IRQs the user has to open up /proc/interrupts, trawl thr= ough > it and identify the correct IRQ number for their given NIC and qid (the f= ormat > for which is unlikely to be known off-hand), and manually pin them by wri= ting > 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 te= rrible > performance. Hi, Following this up with some performance data which shows the impact of no p= inning. The test case is N instances of testpmd macswap where N=3D the number of in= terfaces. ifaces no pinning pinning 1 9059100 9171612 2 9261635 18376552 3 9332804 27696702 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, 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? >=20 > Let me know what you think. >=20 > Thanks, > Ciara