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 EF342A0551 for ; 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 CA64E1BFC8; Fri, 21 Feb 2020 10:40:27 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 82A362B91 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-281-iA9TXXwOPJuFcPANjLEClA-1; Fri, 21 Feb 2020 04:40:21 -0500 Received: by mail-vs1-f70.google.com with SMTP id y15so129953vso.0 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=AUisjrzyXJFfUHaMHg9C/6mVFQmvrjEGn2wRjAFe9oLrZi8T47/8zyi4G0B1X5OTTA X2lqqyG7RP6JJwm38YxG4EG7FOsDaWzCDkZHEP+36LslIrr4bdxoTrgIPW8hqGibJAne L+ArFkAIl+k+wK/KbaqxFRL9uj6ORBl2fq4gtE8w1l0GmDeT4E3Y8lx5dwW5hUsKHwdl xmX/rnuxaJ2C558WAj7chQoYT+exwFa45mIj/8BO+1ticDG5AFWveOILxgXKEWIS9R6Y AfvhtuXXAzThsWMsIZrit79nHDR73+xw37uSpPyUAjBPxX0ra+wtXVSBh+607olujiDk QX6Q== X-Gm-Message-State: APjAAAWIs6izRiSmHt0wLpLYjk+T8rVrY8EiovVhcRn8KnoZN+/j97Qb Nf96bGnZEkDIsbndF/DWWI2YXf/HgwA9veNwTV0YI8YzkT9Aj/H6zbmjx+8opu+4VlrlbaqX6eU H1Q7w2gV4Hu+dGfW3RIKmQpw= X-Received: by 2002:ab0:488b:: with SMTP id x11mr18310183uac.86.1582278021302; 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: iA9TXXwOPJuFcPANjLEClA-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-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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