From: "Song, Keesang" <Keesang.Song@amd.com> To: Thomas Monjalon <firstname.lastname@example.org> Cc: David Marchand <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, Aman Kumar <firstname.lastname@example.org>, "Grimm, Jon" <Jon.Grimm@amd.com> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE Date: Tue, 9 Jun 2020 16:30:06 +0000 Message-ID: <BY5PR12MB3681696FBAAF9D83B52A8A2A96820@BY5PR12MB3681.namprd12.prod.outlook.com> (raw) In-Reply-To: <BY5PR12MB3681C6BECD34662B11430CFB968A0@BY5PR12MB3681.namprd12.prod.outlook.com> [AMD Public Use] Hi Kevin and Luca, 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. Thanks, Keesang -----Original Message----- From: Song, Keesang Sent: Monday, June 1, 2020 3:54 PM To: Thomas Monjalon <email@example.com> Cc: David Marchand <firstname.lastname@example.org>; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; Aman Kumar <firstname.lastname@example.org>; Grimm, Jon <Jon.Grimm@amd.com> Subject: RE: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE [AMD Public Use] Thanks Thomas for the response. For a correction, the patchwork has not been submitted for the current LTS release, 19.11.2, but was merged into 20.02 and onward. The reason I brought this again was to address LTS users and many other application based on the LTS releases(18.11 & 19.11). Since I found many of our customers and users are still relying on the latest LTS version, I'm seeking an aid for adding this change into at least 19.11, LTS branch. We could argue that this is actually not a bug, in a way, it's inconvenient 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 19.11), then can we instead consider changing only the default value of ' CONFIG_RTE_MAX_LCORE' to 256 in common_base file? # Compile Environment Abstraction Layer # CONFIG_RTE_MAX_LCORE=128 --> 256 I'd appreciate if anyone can advise me know what we can do about this to move forward. -----Original Message----- From: Thomas Monjalon <email@example.com> Sent: Monday, June 1, 2020 2:23 PM To: Song, Keesang <Keesang.Song@amd.com> Cc: David Marchand <firstname.lastname@example.org>; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE [CAUTION: External Email] 29/05/2020 05:05, Song, Keesang: > Hi Thomas & David, > > We haven't got the final status on this patch, and I don't see this change 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? > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > hwork.dpdk.org%2Fpatch%2F63507%2F&data=02%7C01%7CKeesang.Song%40am > d.com%7Cd71ea9aca917447dfb3e08d80671f34c%7C3dd8961fe4884e608e11a82d994 > e183d%7C0%7C0%7C637266433776198364&sdata=1EgxevCILVMMLgyQC%2FzaWYJ > XJ%2BOijs0Rtym1TA0VS28%3D&reserved=0 As you can see below, there is a pending question: "is it a new feature or a fix?" Kevin and Luca are the arbiters for the backports in 18.11 and 19.11. > -----Original Message----- > From: Thomas Monjalon <firstname.lastname@example.org> > Sent: Friday, February 21, 2020 12:04 AM > > Hi, > > 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 > > > system has more cores than RTE_MAX_LCORE. > > > A bit of a pity when you get a system with more than 200+ cores > > > and your testpmd has been built and packaged with RTE_MAX_LCORE == 128. > > > > > > The --lcores does not need to care about the underlying cores, > > > 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 > > > > The patches look good but it is very hard to review parsing code (last patch). > > We will better experience corner cases after merging. > > > > Applied for -rc1, thanks > > This patch was merged in 20.02. > We don't have any feedback about issues so it's probably working fine. > > It is solving a problem for running DPDK on machines having a lot of cores. > Now the difficult question: is it a new feature or a fix? > Should we backport this patchset?
next prev parent reply other threads:[~2020-06-10 13:38 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <email@example.com> 2019-12-02 15:41 ` [dpdk-stable] [PATCH 1/4] eal/windows: fix cpuset macro name David Marchand [not found] ` <2076701.vBoWY3egPC@xps> 2020-02-21 8:04 ` [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE Thomas Monjalon 2020-02-21 8:19 ` Song, Keesang 2020-02-21 9:40 ` David Marchand 2020-02-21 14:48 ` Aaron Conole 2020-02-21 16:38 ` Stephen Hemminger 2020-05-29 3:05 ` Song, Keesang 2020-05-29 3:05 ` Song, Keesang 2020-06-01 21:22 ` Thomas Monjalon 2020-06-01 22:54 ` Song, Keesang 2020-06-09 16:30 ` Song, Keesang [this message] 2020-06-09 17:48 ` Luca Boccassi 2020-06-09 21:34 ` Kevin Traynor
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=BY5PR12MB3681696FBAAF9D83B52A8A2A96820@BY5PR12MB3681.namprd12.prod.outlook.com \ --firstname.lastname@example.org \ --cc=Jon.Grimm@amd.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
patches for DPDK stable branches This inbox may be cloned and mirrored by anyone: git clone --mirror https://inbox.dpdk.org/stable/0 stable/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 stable stable/ https://inbox.dpdk.org/stable \ email@example.com public-inbox-index stable Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.dpdk.org/inbox.dpdk.stable AGPL code for this site: git clone https://public-inbox.org/public-inbox.git