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 A3266A0525; Fri, 21 Feb 2020 15:49:11 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BAF834C81; Fri, 21 Feb 2020 15:49:10 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id CDE6034F3 for ; Fri, 21 Feb 2020 15:49:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582296548; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=04ylD6aIFZM5kDCYcjrM8UyDl3yFuFswU7uNwUZUPUU=; b=B7Djz3yleCriL6vhsOpP59vX39ODwOZKnRofFixfYpjS2kxbeSOAY+LFY3O6/nah0SWtSX EizpQyqyzAL/QwhJEOpIJ4D4lE7wwmox27OLxGi+2W+BjMXlM51ToGnuarOQGUgCecOmHw AulstkxDSDEGslk2mNC26G05y0A6QRw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-289-n7O86uXxMnGMV-FbM2m2Cw-1; Fri, 21 Feb 2020 09:49:06 -0500 X-MC-Unique: n7O86uXxMnGMV-FbM2m2Cw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2573F8017DF; Fri, 21 Feb 2020 14:49:04 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-124-152.rdu2.redhat.com [10.10.124.152]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 633C26E3EE; Fri, 21 Feb 2020 14:48:59 +0000 (UTC) From: Aaron Conole To: David Marchand Cc: "Song\, Keesang" , "ktraynor\@redhat.com" , "bluca\@debian.org" , Thomas Monjalon , "dev\@dpdk.org" , "ferruh.yigit\@intel.com" , "bruce.richardson\@intel.com" , "honnappa.nagarahalli\@arm.com" , "drc\@linux.vnet.ibm.com" , "stable\@dpdk.org" , "Grimm\, Jon" , "Hollingsworth\, Brent" References: <20191202153559.9709-1-david.marchand@redhat.com> <2076701.vBoWY3egPC@xps> <5572457.lOV4Wx5bFT@xps> Date: Fri, 21 Feb 2020 09:48:58 -0500 In-Reply-To: (David Marchand's message of "Fri, 21 Feb 2020 10:40:09 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE 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" David Marchand writes: > On Fri, Feb 21, 2020 at 9:19 AM Song, Keesang wrot= e: >> >> [AMD Official Use Only - Internal Distribution Only] > > Please, get this header removed. > This is a public mailing list. > > >> Thanks Thomas for bringing this up. >> I consider this is not a new feature, but rather a fix to address >> the issue with statically assigned maximum lcore limit on >> high-density CPU platform such as AMD Epyc. >> As I see a lot of DPDK adopters are still using LTS 18.11 & 19.11, >> and they have 1~2 yrs of lifetime left, we like to backport this to >> LTS 18.11 & 19.11 at least. > > It is not a fix. > > The use of static arrays is a design choice that goes back to the > early days in dpdk. > The addition of --lcores came in after this, but it was introduced for > a different use case than placing lcores on any physical core. > And there was no claim that a core > RTE_MAX_LCORE would be usable. > > > When testing on a new hardware, it is normal to observe some limitations. > Running DPDK on those platforms should be possible: "should be" > because I do not have access to this hardware and saw neither tests > reports nor performance numbers. > Before this patch, the limitation is that on Epyc, cores > > RTE_MAX_LCORE are not usable. > > > Now, this change is quite constrained. > If we backport it, I don't expect issues in the main dpdk components > (based on code review and ovs tests with a RTE_MAX_LCORE set to 16 on > a 24 cores system). > There might be issues in some examples or not widely used library > which uses a physical core id instead of a lcore id. > > > This is the same recurring question "do we allow new features in a > stable branch?". Usually, the answer is 'no'. But we do allow some "new" things to be backported (pci ids, etc) that might be required to enable older functionality. Additionally, I'm sure if some feature were required to mitigate a CVE, we'd rather favor backporting it. I guess we could pose a litmus test: 1. Is the problem this feature solves so widespread that it needs to be addressed ASAP? 2. Is there a known workaround to the problem this is solving? 3. How intrusive is the feature? 4. Is it shown to be stable in the mainline (number of fixes, testing, etc)? 5. Is it constrained enough that we know we can support it with even higher priority than other things? Probably other questions that will need to be asked. And even in that list of question, I'm not sure I'd be able to advocate backporting this in the upstream branches - it hasn't had much testing. It's unstable. It's "difficult" to use. It is not widespread that people have so many cores. The workaround is much simpler than supporting this (recompile). > > -- > David Marchand