On 09/06/2020 18:48, Luca Boccassi wrote: > On Tue, 2020-06-09 at 16:30 +0000, Song, Keesang wrote: >> [AMD Public Use] >> >> Hi Kevin and Luca, >>
Hi Keesang >> 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 > > 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 > Looks ok to me too. I can take this in 18.11, but it will need to be in 19.11 first. Please send a backport for 18.11 and test that it's working as expected with the 18.11 branch. thanks, Kevin. >> -----Original Message----- >> From: Song, Keesang >> Sent: Monday, June 1, 2020 3:54 PM >> To: Thomas Monjalon <tho...@monjalon.net> >> Cc: David Marchand <david.march...@redhat.com>; dev@dpdk.org; >> acon...@redhat.com; ferruh.yi...@intel.com; bl...@debian.org; >> ktray...@redhat.com; bruce.richard...@intel.com; >> honnappa.nagaraha...@arm.com; d...@linux.vnet.ibm.com; sta...@dpdk.org; Aman >> Kumar <aman.ku...@vvdntech.in>; Grimm, Jon <jon.gr...@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 <tho...@monjalon.net> >> Sent: Monday, June 1, 2020 2:23 PM >> To: Song, Keesang <keesang.s...@amd.com> >> Cc: David Marchand <david.march...@redhat.com>; dev@dpdk.org; >> acon...@redhat.com; ferruh.yi...@intel.com; bl...@debian.org; >> ktray...@redhat.com; bruce.richard...@intel.com; >> honnappa.nagaraha...@arm.com; d...@linux.vnet.ibm.com; sta...@dpdk.org >> 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 <tho...@monjalon.net> >>> 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? >