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 076E9A0519 for ; Tue, 9 Jun 2020 23:34:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B63861DB9; Tue, 9 Jun 2020 23:34:29 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id E758C1DB9 for ; Tue, 9 Jun 2020 23:34:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591738467; 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:autocrypt:autocrypt; bh=qzCAT1Zcjv/a5RHp/79Jdabh+7Pk4eAdoM0yfLMLK5I=; b=gZb8JxLE49+EJKUM2jNOr3+Kikcg3jfNMYBx205jmrp5vDlTyrUjwkmEpkNnv3tjAuUlkG RBMbnZU4tASZlY3FCkKPbtW7zUweiHsvYzc4kcWqHqypre6CtHr2YdhkKqYXf8xtZoHs0v JIfpBQ8/+qyPO68YE4r3EZM4VDy2x3s= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-273-jOsBEBEGNa-DEG7nh1Long-1; Tue, 09 Jun 2020 17:34:23 -0400 X-MC-Unique: jOsBEBEGNa-DEG7nh1Long-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 336C3835B40; Tue, 9 Jun 2020 21:34:20 +0000 (UTC) Received: from [10.33.36.227] (unknown [10.33.36.227]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6F60360C84; Tue, 9 Jun 2020 21:34:13 +0000 (UTC) To: Luca Boccassi , "Song, Keesang" , Thomas Monjalon Cc: David Marchand , "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" , Aman Kumar , "Grimm, Jon" References: <20191202153559.9709-1-david.marchand@redhat.com> <3762540.mo1vFcNuoO@thomas> From: Kevin Traynor Autocrypt: addr=ktraynor@redhat.com; keydata= mQINBF2J2awBEADUEPNhgNI+nJNgiTAUcw4YIgVXEoHlsNPyyzG1BEXkWXALy0Y3fNTiw6+r ltWDkF9jzL9kfkecgQ67itGfk1OaBXgSGKuw1PUpxAwX2Bi76LAR6M5OsyGM9TSVVQwARalz hMwRBIZPzPc7or6Pw7jAOJ8SQGJ1Zlp1YJCjrvpe87V1tH/LY8Wnxn/EuoseFmWILAQZAtYS tGjcrAgYn3SPMLR1B0BP5bTBY06vWQjiufH8drenfDnMJAzuBdG1mqjnTqCjULZ3Hunv4xqZ aMnkvL/K5Tj1c12Oe4930EE53LrXIBUltRg5mBudSWHnC7twjH0082HH9f963Z/2UI63SFIT iUvRvAzJYytgy7XnWLQ0+goZBADKYfolOuC0H8VgCaux8u8KFF28Dy+N6TV2KI58jTlyg1Zu l7QwykZpnOkJFiy37Gfbu3YEOzO72cP/S7/A+zvuqkxi63jyEkd+FY99vLt/HN2MUZwRmKDw UPbLkmrs8WU01/POVsqDcfvz7vu2St8hqqTiSIdQGS2zyTKB2/DvPSM3jws3udkIYSuhn+X4 QBiV6lkVZ7DSE6a065gnAauAql+b32Eymy+xnG5jCt1tR+0Cp2VZYCR9OU2gmomUKBDoX/He pSgED01CqYPNjN+TddirwmQX7ep4DtXc8FWvv2g/pq9WZFQk2QARAQABtCNLZXZpbiBUcmF5 bm9yIDxrdHJheW5vckByZWRoYXQuY29tPokCTgQTAQgAOBYhBAoiOaH51tHF7VYtEI9CINER a+yJBQJdidmsAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEI9CINERa+yJoxIP/3VF 2TIgW4ckxhRFCvFu/606bnvCPie88ake4uWVWMAWwcMc4fKEltRWRCpkSVOwgqoMHnyHxK5r kOKzx2CLJMX5TgTMfKzPuaBDHngHLUzl2DStpBzrod0cVg5TShdmmfjY61uxRJKz+DlSkwgJ riADdVF5PPosQXTkKSGf2ombpTGpx/pue9ocjnr3x4SDpRLlnooM6Jf/3Y3Ib4jX6HPEyWuY b+owIIk9y2nRRGPQ6jbqAhsrXd9V+77UL0QuGWloMuKMZFbNg8hbu7X5aFijAbfxj4YUgojS ba7gfGZQan8h32A9KGQWrmsCBc3j2GqEPsX0r05X7cn7WL6IOPgQJ5EiQ7PlazQYVLrvZg9B n0GKK0k6895mLG0ZZ5v/qajOPF52etSmvFD1WUPb4OqaHqGA9ZtMpaKFRt7Y6rpXqKNU1xzW F5KjbTPtTb9WF3An8dciVv+AYUI7totkZYkWvQtgss8lfaX3NKUvXLVxqK0z3dQyr7rF/tYz PneTKypSksjCgaEBLSrsRmM5zKfe7tSNF/fDntfIq/029Jtcw29TcWEP57peNu6TtejewQD9 sTI+oqiXvW2D5l7LNUDYG8eMJp2oT7I0ZSBRvwcbmjH0DtN/bXCCFfCvk8Yic68F3tV1ctix wQARVKDBhT30uCxycRWojCYqTgNJJS71uQINBF2J2awBEADP57PR2IpSYBeNSrsAjeIcsahE N4SQP2C4s50S8QEWAUhqMRI7WNv5cfeef0nDvcl1IUA6oz5SokbcsbMa+mRgaNF4N5KikWTO LPYxq2YVJoXwJ+tKmNzyOLFUIfFJ4NBJZple5dTfWzD00Dbb19Mri1hy1mWMqNTPGBee1+hw Qcp6n3mmGECvajs8G5A7NyXbwL8ihN7HX9D01ucD62b4G03yKe2g/hvKgcdUVmhCldJlF27I 2fSR9tDxH9pZqRODY4rjbFZEey/vWKXqjE+DQ8AtMSEaDfFe5D+i4Aw6erWQ3Wr+DwZt1/7G dIAElGA/q90T1ENVwJX9y7fsQssawKYYdDqURHCl5JuDXI+VXUypExipUUT5SPycMmbLsx0D iKEqPPDQWKxkIDVKqj2+EhamSuJznZUwBLJKn0h4zrIWiXWUy07lRwtVuhaDXhF3GfW+5W/x wAg7Qg3w00ASsb/XTHBIhMnenKDfS7ihtQA8SacwX8ySdxb+15XPyiplM979qBQ0mhnilulm MIJzEf/JxoYR5huuj4f1PFqqrsP06Dl+YGB7dQZp3IKggS5c3/TAynARRg9N89UsDXNtp7X0 tgIPFF5k6fnHE0J5O64GYHeTqN/1aE6dAEOV9WrGzQAJxU9ipikb8jKAWXzLewRIKGmoPcRZ WdB0NmIjmQARAQABiQI2BBgBCAAgFiEECiI5ofnW0cXtVi0Qj0Ig0RFr7IkFAl2J2awCGwwA CgkQj0Ig0RFr7IkkORAAl/NbX93WK5MEoRw7/DaPTo/Lo6Pj1XMeSqGyACigHK/452UDvlEH NjNJMzYYrNIjMtEmN9VVCfjT38CSca7mpGQVwchc0mC7QSPAETLCS+UacVf/Kwxz5FfkEUUw UT7A+uyVOIgW3d9ldlRzkHA2czonSSgTQU+i2g6DM4ha+BuQb4byAXH6HQHt/Zh1J64z0ohH v6iGsCzCY/sMWF8+LEGSnzMGRCLiiwSF0vJBHbzWK68fANaF4gBV0Z/+6tQRFN7YMhj/INmk qgvHj1ZzHFNtirjMGPRxoZs51YoLQM/aBPxKrnmXThx1ufH+0L6sGmFTugiDt0XSEkC5reH7 a+VhQ1VTFFQrClA8NmDSPzFeuhru4ryaaDHO+uEB16cNHxHrQtlP/2hts2JM5lwkZRWJ5A57 h8eDEIK5be47T85NVHfuTaboNRmgg1HygVejhGUtt69u/0MVRg/roUTa0FyEbNsvz4qAecyW yWzMcVrcGJDQLC9JLKEpoyUF6gdTKaiDL2Vao4+XRIA3Y57b6MO35a3HuzAv7+i5Z0mnDEJO XxXqTOmKYpMIGexzM/PtuA0712sT1abG9tAJ17ao/B7cqMW5IkKkalemFbWfI2unns4Papvo tk9igVqyp6EJDU98z5TJioCVojwK2laDaoIjTJk9YYv3iwCsqPd5feU= Message-ID: <45aa8f36-f973-f03a-6df5-73a428c7605b@redhat.com> Date: Tue, 9 Jun 2020 22:34:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 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 >> Cc: David Marchand ; dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org; Aman Kumar ; Grimm, Jon >> 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 >> Sent: Monday, June 1, 2020 2:23 PM >> To: Song, Keesang >> Cc: David Marchand ; dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@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 >>> 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? >