Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1950969ybt; Mon, 15 Jun 2020 13:52:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxv5xeVnXDZWUbixiRKInM/TdSiDR7kXD5/8IwFch1eFyjFwchDhFPap146hEVuGMo1/RNC X-Received: by 2002:a50:f28e:: with SMTP id f14mr26512838edm.100.1592254361041; Mon, 15 Jun 2020 13:52:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592254361; cv=none; d=google.com; s=arc-20160816; b=HJAp+hE50fr+PJYGKUuUSJdrrydRawpHWxEyjuSpFYIoC6lL60oWsT5EqEim1Fo7EX 9cOsvuFP/+1P6uudIEWje4q5Dgp6eSN5Z0JS8WBvfOmze4QTpS3DQSZV3eCmooNUYvsZ oUqdpJ22Ftv9B93WeMFgfhZo4robpUkdpDFFOxrOWZkDEZjWy+pkyMGnLAfsbG2XHeEa kPlfx1cbqIa9GgN7V619VmoBqXQCCrenl/xVHigQrywL2X4aVxz24IZzaGe2rLkEr3e3 unBN8O1vBKfgYJJ9WuOu3IQ1YZQQVNKVnozswtRGKHLz/S58w0uUHN+rWHceFxjVZMxE eWpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :dlp-reaction:dlp-version:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:to:from:ironport-sdr:ironport-sdr; bh=FfPmuoODUNFFL8E3CPLQ1KQrfQDHmTUWXQ7JRtrlwQg=; b=yzXnxCqBWwZxCMjWp7UvCZLUEvymepeU/ki8sp8WPTMCwE7G1zufVD4P6QWNvrLfc6 S336ip/16Oywd/Uk+QrzArF6v2gOoW+6OJLhRT2+nayGXlmoHX3tm2hUIoBqm+CrWNTm Ghj9yHnikOyPPI3PkeDaCl4JMzsxTXM3d6P214p7CTCJbN9cgFfECkd9Xd91lKVj2yhX KGgEmTUooHuARfjw/F+zt2vQ1Uh70y2FDLkY4Wl2nXOc7IEYKivInezrzTzkMmSpx6gS +YTjCLt1+j7uSLR0r/oVX10kZtvGSCtKdC1wFm5bIbXnj9ZjqjN/TLYZCfVkaMMBm1s3 yY5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z39si5036321ede.374.2020.06.15.13.52.18; Mon, 15 Jun 2020 13:52:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731451AbgFOUsY convert rfc822-to-8bit (ORCPT + 99 others); Mon, 15 Jun 2020 16:48:24 -0400 Received: from mga07.intel.com ([134.134.136.100]:11797 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729692AbgFOUsX (ORCPT ); Mon, 15 Jun 2020 16:48:23 -0400 IronPort-SDR: wv8Hm55XLfxdWJ2Kn8lpWzH6ZAiyJHSJBcFqKgQeB31p+UkLct1f2FTCac0BdblIyCzU8aAild QfAoi/L8XTAw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jun 2020 13:48:22 -0700 IronPort-SDR: Am/SKLeJ8b43icXAXBUuywBBQBFzKMk1G/MzbnK6Jx0ZG6mgW369the8WlUoZK4qJ+yTrSuS7Y Iblsn38rPnFA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,516,1583222400"; d="scan'208";a="308862080" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga002.fm.intel.com with ESMTP; 15 Jun 2020 13:48:22 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 15 Jun 2020 13:48:21 -0700 Received: from fmsmsx102.amr.corp.intel.com ([169.254.10.33]) by fmsmsx156.amr.corp.intel.com ([169.254.13.189]) with mapi id 14.03.0439.000; Mon, 15 Jun 2020 13:48:21 -0700 From: "Keller, Jacob E" To: Nitesh Narayan Lal , "linux-kernel@vger.kernel.org" , "frederic@kernel.org" , "mtosatti@redhat.com" , "sassmann@redhat.com" , "Kirsher, Jeffrey T" , "jlelli@redhat.com" Subject: RE: [Patch v1] i40e: limit the msix vectors based on housekeeping CPUs Thread-Topic: [Patch v1] i40e: limit the msix vectors based on housekeeping CPUs Thread-Index: AQHWQ1KUwSgU+rT5bUSl1INlbp/95KjaJWLQ Date: Mon, 15 Jun 2020 20:48:21 +0000 Message-ID: <02874ECE860811409154E81DA85FBB58C25F8001@FMSMSX102.amr.corp.intel.com> References: <20200615202125.27831-1-nitesh@redhat.com> <20200615202125.27831-2-nitesh@redhat.com> In-Reply-To: <20200615202125.27831-2-nitesh@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.1.200.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Nitesh Narayan Lal > Sent: Monday, June 15, 2020 1:21 PM > To: linux-kernel@vger.kernel.org; frederic@kernel.org; mtosatti@redhat.com; > sassmann@redhat.com; Kirsher, Jeffrey T ; Keller, > Jacob E ; jlelli@redhat.com > Subject: [Patch v1] i40e: limit the msix vectors based on housekeeping CPUs > > In a realtime environment, it is essential to isolate > unwanted IRQs from isolated CPUs to prevent latency overheads. > Creating MSIX vectors only based on the online CPUs could lead > to a potential issue on an RT setup that has several isolated > CPUs but a very few housekeeping CPUs. This is because in these > kinds of setups an attempt to move the IRQs to the limited > housekeeping CPUs from isolated CPUs might fail due to the per > CPU vector limit. This could eventually result in latency spikes > because of the IRQ threads that we fail to move from isolated > CPUs. This patch prevents i40e to add vectors only based on > available online CPUs by using housekeeping_cpumask() to derive > the number of available housekeeping CPUs. > > Signed-off-by: Nitesh Narayan Lal > --- Ok, so the idea is that "housekeeping" CPUs are to be used for general purpose configuration, and thus is a subset of online CPUs. By reducing the limit to just housekeeping CPUs, we ensure that we do not overload the system with more queues than can be handled by the general purpose CPUs? Thanks, Jake