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 5A1D5A0525; Fri, 21 Feb 2020 10:40:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 857E04C81; Fri, 21 Feb 2020 10:40:26 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 8791C4C81 for ; Fri, 21 Feb 2020 10:40:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582278023; 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=wjNv8cn26hETLKK4Kmr3fj2BuQYmlfkaLq9TshJG5ZI=; b=eV0JN96LC7hsnP3XH6AXj0r2Al37G5Iv481B05xp7Bja5bGej3qLXi1Aucqa9cNfC5XSFR bMEx5qWf3wAmzPqR/TVAK14Qu+sr8eCfLaOkhTmScJkJ6CLVgPcJGcal68rXZJW9PK84zb U2CZ0Z44SDik4M5nCjdSzimc4NFJcp8= Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com [209.85.217.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-471-zCqnAqn0OIeKgT1Rt4b-2w-1; Fri, 21 Feb 2020 04:40:21 -0500 Received: by mail-vs1-f70.google.com with SMTP id r3so124740vsl.14 for ; Fri, 21 Feb 2020 01:40:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BP/XB2/ElPnTjsRK04dyf7sWqDHBsibXa2ow3OZbOfE=; b=ko0Yi0JbYIlw/0seS3lm9pIFWg7ZFT0FhAzzjTbUHJW+y05R4YnO5yq/AAW5WjljWq 1hxITqHR5GdgMhExPLUGc19ePBjvf8T9bUyEZyuN58tM6DfxsG62PvAZL0Omi0A+w1xe 4n/NbVN8sFrPEzznT8vAQgU9BvqIDXsbiaJJoeaQNGNbdbWGwGGN3+WrizD1Ias2IuNO PjKyJ00E9UmYvqPrXJATbGemwRTbevdN2hw2h94s6j3bgOyH7mvw0vxu/W5j82Ft2RsP 7ReBSAE1LprYUhNpql7o6ytcY21rAQ5KmB1o+U4DtPnbXyNcpCCUot+XpS4/vfgLmmbM q/GQ== X-Gm-Message-State: APjAAAWUqTlFtkwYA7cKGfvc9U2UShbvXkDPgrDI2XSFIdl5Q9FZpKUe dGMGVNv3s5l+obMLesAxKJQ3xDl4BWw3bZAV9k/pctQpaTopocUQoIiMt500FOPpxwzTfqnXMGy YUGHUhe+z4DDtvZWaHDA= X-Received: by 2002:ab0:488b:: with SMTP id x11mr18310178uac.86.1582278021301; Fri, 21 Feb 2020 01:40:21 -0800 (PST) X-Google-Smtp-Source: APXvYqwwNgcG2M74RzCKigjz/2BdIpjZz36RwbY/LL5Tii181NPoHfWosxKgUjd5xOE+WJWlTsAx7FLq/x9PTu6OcZ0= X-Received: by 2002:ab0:488b:: with SMTP id x11mr18310164uac.86.1582278020874; Fri, 21 Feb 2020 01:40:20 -0800 (PST) MIME-Version: 1.0 References: <20191202153559.9709-1-david.marchand@redhat.com> <2076701.vBoWY3egPC@xps> <5572457.lOV4Wx5bFT@xps> In-Reply-To: From: David Marchand Date: Fri, 21 Feb 2020 10:40:09 +0100 Message-ID: To: "Song, Keesang" , "ktraynor@redhat.com" , "bluca@debian.org" Cc: Thomas Monjalon , "dev@dpdk.org" , "aconole@redhat.com" , "ferruh.yigit@intel.com" , "bruce.richardson@intel.com" , "honnappa.nagarahalli@arm.com" , "drc@linux.vnet.ibm.com" , "stable@dpdk.org" , "Grimm, Jon" , "Hollingsworth, Brent" X-MC-Unique: zCqnAqn0OIeKgT1Rt4b-2w-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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" On Fri, Feb 21, 2020 at 9:19 AM Song, Keesang wrote: > > [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 iss= ue with statically assigned maximum lcore limit on high-density CPU platfor= m such as AMD Epyc. > As I see a lot of DPDK adopters are still using LTS 18.11 & 19.11, and th= ey have 1~2 yrs of lifetime left, we like to backport this to LTS 18.11 & 1= 9.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?". -- David Marchand