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 D7D88A04FE; Tue, 9 Jun 2020 19:48:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CE3CE2C60; Tue, 9 Jun 2020 19:48:23 +0200 (CEST) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by dpdk.org (Postfix) with ESMTP id C919D2A62; Tue, 9 Jun 2020 19:48:22 +0200 (CEST) Received: by mail-wm1-f68.google.com with SMTP id l17so3676291wmj.0; Tue, 09 Jun 2020 10:48:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=PGbLp4fdU/FMOzRjyK+uLBIrBWu0uZP7pSS0JwVEcz8=; b=k2qctjuLQP218zDdRzA1wkaGzzxS8c1vNZ2Rmt4808HF+NDLtaau+WpkJcBabkfss2 2PuCxNsYeGRxM57DbFLCHnXkEiY4FivI/3734EubgHjexlJ9jxoNCVpr0YMe66667Efz 081BNMln9BcFlgL7ouUHyFR4kDuXWX8qf7CD9pPy6IRfFDNyVuaRn1+HLp9zsKSfoZ2R UB4OyRmFg0a9EQ1QZD1sATZQFnawPALLn7vRorlz0CyFCloceMVhT7D7g8K7eZimLAqs 8zXtbJ85FVHzCNr1Z1gSVniZ76X5jJYs18huvngeLkj8wFi8RssQjMXddgQuE5omRyCK bJnA== X-Gm-Message-State: AOAM530D0Il5i2EC0dEoZIKfpbNTms2I1DeAuv3TxAkol6+sfPK54tGo V00JaAI9ZbdRSZjZf7+lqRc= X-Google-Smtp-Source: ABdhPJxYTK8aUQB7Ij7RTBQSWmVbTZ8sXflA4Vg72l45iTu1x3DvvPgKS/XJqR1xRXy13yr3tAyPrA== X-Received: by 2002:a1c:2d4d:: with SMTP id t74mr5509399wmt.177.1591724902351; Tue, 09 Jun 2020 10:48:22 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id j5sm4366771wrm.57.2020.06.09.10.48.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 10:48:21 -0700 (PDT) Message-ID: From: Luca Boccassi To: "Song, Keesang" , Thomas Monjalon Cc: David Marchand , "dev@dpdk.org" , "aconole@redhat.com" , "ferruh.yigit@intel.com" , "ktraynor@redhat.com" , "bruce.richardson@intel.com" , "honnappa.nagarahalli@arm.com" , "drc@linux.vnet.ibm.com" , "stable@dpdk.org" , Aman Kumar , "Grimm, Jon" Date: Tue, 09 Jun 2020 18:48:20 +0100 In-Reply-To: References: <20191202153559.9709-1-david.marchand@redhat.com> <3762540.mo1vFcNuoO@thomas> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 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 Tue, 2020-06-09 at 16:30 +0000, Song, Keesang wrote: > [AMD Public Use] >=20 > Hi Kevin and Luca, >=20 > We are still waiting for the response. > Can you help on this for the backports in 18.11 and 19.11? > It would work for our customers even with changing the default value of '= CONFIG_RTE_MAX_LCORE' to 256 in common_base file in 18.11 and 19.11. >=20 > Thanks, > Keesang How to send patches for inclusion in LTS releases if not already backported is documented here: https://core.dpdk.org/contribute/#send If you do the work to backport and test, on the surface it seems fine to have those in 19.11.4 > -----Original Message----- > From: Song, Keesang=20 > Sent: Monday, June 1, 2020 3:54 PM > To: Thomas Monjalon > Cc: David Marchand ; dev@dpdk.org; aconole@red= hat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bru= ce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.c= om; stable@dpdk.org; Aman Kumar ; Grimm, Jon > Subject: RE: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE= _MAX_LCORE >=20 > [AMD Public Use] >=20 > Thanks Thomas for the response. > For a correction, the patchwork has not been submitted for the current LT= S release, 19.11.2, but was merged into 20.02 and onward.=20 > The reason I brought this again was to address LTS users and many other a= pplication based on the LTS releases(18.11 & 19.11). > Since I found many of our customers and users are still relying on the la= test LTS version, I'm seeking an aid for adding this change into at least 1= 9.11, LTS branch. > We could argue that this is actually not a bug, in a way, it's inconvenie= nt for Openstack or cloud deployed DPDK application since it's often inapt = to change the base config and recompile the max lcore limit. > If backporting is still not a preferred way(pushing this patchwork into 1= 9.11), then can we instead consider changing only the default value of ' CO= NFIG_RTE_MAX_LCORE' to 256 in common_base file? >=20 > # Compile Environment Abstraction Layer > # > CONFIG_RTE_MAX_LCORE=3D128 --> 256 >=20 > I'd appreciate if anyone can advise me know what we can do about this to = move forward. >=20 > -----Original Message----- > From: Thomas Monjalon > Sent: Monday, June 1, 2020 2:23 PM > To: Song, Keesang > Cc: David Marchand ; dev@dpdk.org; aconole@red= hat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bru= ce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.c= om; stable@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE= _MAX_LCORE >=20 > [CAUTION: External Email] >=20 > 29/05/2020 05:05, Song, Keesang: > > Hi Thomas & David, > >=20 > > We haven't got the final status on this patch, and I don't see this cha= nge even from the latest LTS 20.04 repo. > > So I'd like to confirm whether this patch has been safely submitted to = the main upstream. > > Can you check the status of that commit? > >=20 > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fpat= c > > hwork.dpdk.org%2Fpatch%2F63507%2F&data=3D02%7C01%7CKeesang.Song%40a= m > > d.com%7Cd71ea9aca917447dfb3e08d80671f34c%7C3dd8961fe4884e608e11a82d994 > > e183d%7C0%7C0%7C637266433776198364&sdata=3D1EgxevCILVMMLgyQC%2FzaWY= J > > XJ%2BOijs0Rtym1TA0VS28%3D&reserved=3D0 >=20 > As you can see below, there is a pending question: > "is it a new feature or a fix?" >=20 > Kevin and Luca are the arbiters for the backports in 18.11 and 19.11. >=20 >=20 > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Friday, February 21, 2020 12:04 AM > >=20 > > Hi, > >=20 > > 21/01/2020 01:24, Thomas Monjalon: > > > 02/12/2019 16:35, David Marchand: > > > > We are currently stuck with no option but recompile a DPDK if the= =20 > > > > system has more cores than RTE_MAX_LCORE. > > > > A bit of a pity when you get a system with more than 200+ cores=20 > > > > and your testpmd has been built and packaged with RTE_MAX_LCORE =3D= =3D 128. > > > >=20 > > > > The --lcores does not need to care about the underlying cores,=20 > > > > remove this limitation. > > > > David Marchand (4): > > > > eal/windows: fix cpuset macro name > > > > eal: do not cache lcore detection state > > > > eal: display all detected cores at startup > > > > eal: remove limitation on cpuset with --lcores > > >=20 > > > The patches look good but it is very hard to review parsing code (las= t patch). > > > We will better experience corner cases after merging. > > >=20 > > > Applied for -rc1, thanks > >=20 > > This patch was merged in 20.02. > > We don't have any feedback about issues so it's probably working fine. > >=20 > > It is solving a problem for running DPDK on machines having a lot of co= res. > > Now the difficult question: is it a new feature or a fix? > > Should we backport this patchset?