Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp2727877rdd; Fri, 12 Jan 2024 22:30:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IGi+uDGTNpdt4YsbMAixNcD5RjW050Gbg31/Eu8/JNd3GsLpMCzIjxULnsJxVezDXYhZ58w X-Received: by 2002:a7b:c413:0:b0:40e:5571:378a with SMTP id k19-20020a7bc413000000b0040e5571378amr735990wmi.198.1705127457274; Fri, 12 Jan 2024 22:30:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705127457; cv=none; d=google.com; s=arc-20160816; b=G3Iq9zu4bjnZRoNWuztReYKeDA/gr8/p8Xw2pThjbTEBQTdFq7e2QZi4W5d+LXw9lv tcJlMD/F+ejsbKMe0ENaGQ6OOck9uV8fC8S3i/m0mKHB4zhbjKvCHozLX5D9mxdCeH1G p+X6Y0f66QC5nzJvg7T9lmr7KTaqLA3GUUz0bdmybEGSEWsKjeZO/CmHWFaYviSzVbWz hHfjjpzWMMBhQVuWV2FvkkiK55ZnNGQw5QXFZtxonwLzx57k464thXwWuFOoKWXFXkGo WmzEy9lN//R6B6jsySX+qrPxVnl7UTfEaS6v8X/ElGE2xG2U/Gb+oatDjGtP7Lfr8bnn qz8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:references :message-id:subject:cc:to:from:date:dkim-signature:dkim-filter; bh=fxr73g95E5MYVxFDJezyB06iH7LUFljRdUOESeGdmAY=; fh=qgVX8DRj1C/aW83P2HPrWJcHcZNuGEQ2jZQJ7XgHsB0=; b=rEqSHuB1fZt0awIzG9okd6aeMeH7OdTAdsUuQKjOSKwU5U7j1Rx/3LSr5H1HHLdpQB n0qpbmPhc6zJtL+Do/90VQK0h5sHk8RBePFt9MSkuORwszgvJskwxgwnnZt07AEsfXUu JbN92CQwLYIY808JI20iXo5NrvGKOYnM+qH5Mv4pCaE9MN40H5d2qe4r42bNT4Ft32z5 MQgFPaoeTyGvX3CNgWcY5W6sjpBtqVtQiZBAmjlLNLtOtQP5AhScZ1ks5F5uj7cyGADl 2KEK6YbDAmmYzytC9EguU8SKspKwo6KxUqegXBStfwG0RI+Y6JYwCuHz5zYADCpa01m0 Xo2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=SrEsonQz; spf=pass (google.com: domain of linux-kernel+bounces-25202-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25202-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id ig7-20020a056402458700b00558ac149787si1842131edb.676.2024.01.12.22.30.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 22:30:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-25202-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=SrEsonQz; spf=pass (google.com: domain of linux-kernel+bounces-25202-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25202-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 2BDA11F210CA for ; Sat, 13 Jan 2024 06:30:55 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 232BA168C2; Sat, 13 Jan 2024 06:30:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="SrEsonQz" Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 67BD537E; Sat, 13 Jan 2024 06:30:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Received: by linux.microsoft.com (Postfix, from userid 1099) id E26B720B3CF2; Fri, 12 Jan 2024 22:30:38 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E26B720B3CF2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1705127438; bh=fxr73g95E5MYVxFDJezyB06iH7LUFljRdUOESeGdmAY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SrEsonQzos//LpGrhTt/KpAAuKXgfq2LLUhR+r/WtOWmPUq0kGwI0FWVaJnDZ5Shq 9SSiDkPDM7+uIRgr+gGQHLxWvr1TIaa6mdzu6cUVOch6gr776H5MgCABBgtyNj/4Uf fEEIm9nspmAhiaBZKHdl+/ySsPtOQE+O4XrIkMLk= Date: Fri, 12 Jan 2024 22:30:38 -0800 From: Souradeep Chakrabarti To: Haiyang Zhang Cc: Michael Kelley , Yury Norov , KY Srinivasan , "wei.liu@kernel.org" , Dexuan Cui , "davem@davemloft.net" , "edumazet@google.com" , "kuba@kernel.org" , "pabeni@redhat.com" , Long Li , "leon@kernel.org" , "cai.huoqing@linux.dev" , "ssengar@linux.microsoft.com" , "vkuznets@redhat.com" , "tglx@linutronix.de" , "linux-hyperv@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , Souradeep Chakrabarti , Paul Rosswurm Subject: Re: [PATCH 3/4 net-next] net: mana: add a function to spread IRQs per CPUs Message-ID: <20240113063038.GD5436@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1704797478-32377-1-git-send-email-schakrabarti@linux.microsoft.com> <1704797478-32377-4-git-send-email-schakrabarti@linux.microsoft.com> <20240111061319.GC5436@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) On Fri, Jan 12, 2024 at 06:30:44PM +0000, Haiyang Zhang wrote: > > > > -----Original Message----- > > From: Michael Kelley > > Sent: Friday, January 12, 2024 11:37 AM > > To: Souradeep Chakrabarti > > Cc: Yury Norov ; KY Srinivasan ; > > Haiyang Zhang ; wei.liu@kernel.org; Dexuan Cui > > ; davem@davemloft.net; edumazet@google.com; > > kuba@kernel.org; pabeni@redhat.com; Long Li ; > > leon@kernel.org; cai.huoqing@linux.dev; ssengar@linux.microsoft.com; > > vkuznets@redhat.com; tglx@linutronix.de; linux-hyperv@vger.kernel.org; > > netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > > rdma@vger.kernel.org; Souradeep Chakrabarti ; > > Paul Rosswurm > > Subject: RE: [PATCH 3/4 net-next] net: mana: add a function to spread > > IRQs per CPUs > > > > [Some people who received this message don't often get email from > > mhklinux@outlook.com. Learn why this is important at > > https://aka.ms/LearnAboutSenderIdentification ] > > > > From: Souradeep Chakrabarti Sent: > > Wednesday, January 10, 2024 10:13 PM > > > > > > The test topology was used to check the performance between > > > cpu_local_spread() and the new approach is : > > > Case 1 > > > IRQ Nodes Cores CPUs > > > 0 1 0 0-1 > > > 1 1 1 2-3 > > > 2 1 2 4-5 > > > 3 1 3 6-7 > > > > > > and with existing cpu_local_spread() > > > Case 2 > > > IRQ Nodes Cores CPUs > > > 0 1 0 0 > > > 1 1 0 1 > > > 2 1 1 2 > > > 3 1 1 3 > > > > > > Total 4 channels were used, which was set up by ethtool. > > > case 1 with ntttcp has given 15 percent better performance, than > > > case 2. During the test irqbalance was disabled as well. > > > > > > Also you are right, with 64CPU system this approach will spread > > > the irqs like the cpu_local_spread() but in the future we will offer > > > MANA nodes, with more than 64 CPUs. There it this new design will > > > give better performance. > > > > > > I will add this performance benefit details in commit message of > > > next version. > > > > Here are my concerns: > > > > 1. The most commonly used VMs these days have 64 or fewer > > vCPUs and won't see any performance benefit. > > > > 2. Larger VMs probably won't see the full 15% benefit because > > all vCPUs in the local NUMA node will be assigned IRQs. For > > example, in a VM with 96 vCPUs and 2 NUMA nodes, all 48 > > vCPUs in NUMA node 0 will all be assigned IRQs. The remaining > > 16 IRQs will be spread out on the 48 CPUs in NUMA node 1 > > in a way that avoids sharing a core. But overall the means > > that 75% of the IRQs will still be sharing a core and > > presumably not see any perf benefit. > > > > 3. Your experiment was on a relatively small scale: 4 IRQs > > spread across 2 cores vs. across 4 cores. Have you run any > > experiments on VMs with 128 vCPUs (for example) where > > most of the IRQs are not sharing a core? I'm wondering if > > the results with 4 IRQs really scale up to 64 IRQs. A lot can > > be different in a VM with 64 cores and 2 NUMA nodes vs. > > 4 cores in a single node. > > > > 4. The new algorithm prefers assigning to all vCPUs in > > each NUMA hop over assigning to separate cores. Are there > > experiments showing that is the right tradeoff? What > > are the results if assigning to separate cores is preferred? > > I remember in a customer case, putting the IRQs on the same > NUMA node has better perf. But I agree, this should be re-tested > on MANA nic. 1) and 2) The change will not decrease the existing performance, but for system with high number of CPU, will be benefited after this. 3) The result has shown around 6 percent improvement. 4)The test result has shown around 10 percent difference when IRQs are spread on multiple numa nodes. > > - Haiyang >