From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2ADEC42D0E; Wed, 21 Jun 2023 06:00:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BD35440DFB; Wed, 21 Jun 2023 06:00:35 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id B6C9240DDC; Wed, 21 Jun 2023 06:00:34 +0200 (CEST) Received: from kwepemi500012.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Qm8pT5WQBzMnD2; Wed, 21 Jun 2023 11:57:21 +0800 (CST) Received: from [10.78.231.32] (10.78.231.32) by kwepemi500012.china.huawei.com (7.221.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 21 Jun 2023 12:00:29 +0800 Message-ID: <96f88348-ca06-b584-0e57-961bab20f3ec@huawei.com> Date: Wed, 21 Jun 2023 12:00:28 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0.3 Subject: Re: [PATCH v3] net/bonding: fix bond startup failure when NUMA is -1 To: Ferruh Yigit , =?UTF-8?Q?Niklas_S=c3=b6derlund?= CC: Chaoyong He , , , Zerun Fu , , Peng Zhang , Long Wu , Thomas Monjalon , David Marchand References: <20230616071558.1278520-1-chaoyong.he@corigine.com> <20230616072034.1278546-1-chaoyong.he@corigine.com> <3237ae77-bd68-cffa-f1f6-537ff871496e@amd.com> <5eceb17a-adf4-11e3-4274-0d6e111b091d@huawei.com> <0cda2d4a-1deb-9024-9578-de98082c6ffc@amd.com> From: "humin (Q)" In-Reply-To: <0cda2d4a-1deb-9024-9578-de98082c6ffc@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.78.231.32] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemi500012.china.huawei.com (7.221.188.12) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 在 2023/6/20 22:10, Ferruh Yigit 写道: > On 6/20/2023 2:15 PM, humin (Q) wrote: >> Hi, Niklas, Ferruh, >> >> 在 2023/6/20 19:03, Niklas Söderlund 写道: >>> Hi Connor and Ferruh, >>> >>> On 2023-06-19 09:57:17 +0100, Ferruh Yigit wrote: >>>> On 6/16/2023 1:00 PM, humin (Q) wrote: >>>>> Hi, >>>>> >>>>> 在 2023/6/16 15:20, Chaoyong He 写道: >>>>>> From: Zerun Fu >>>>>> >>>>>> After the mainline Linux kernel commit >>>>>> "fe205d984e7730f4d21f6f8ebc60f0698404ac31" (ACPI: Remove side effect >>>>>> of partly creating a node in acpi_map_pxm_to_online_node) by >>>>>> Jonathan Cameron. When the system does not support NUMA architecture, >>>>>> the "socket_id" is expected to be -1. The valid "socket_id" in >>>>>> BOND PMD is greater than or equal to zero. So it will cause an error >>>>>> when DPDK checks the validity of the "socket_id" when starting the >>>>>> bond. This commit can fix this bug. >>>>>> >>>>>> Fixes: f294e04851fd ("net/bonding: fix socket ID check") >>>>>> Cc: stable@dpdk.org >>>>>> >>>>>> Signed-off-by: Zerun Fu >>>>>> Reviewed-by: Peng Zhang >>>>>> Reviewed-by: Chaoyong He >>>>>> Reviewed-by: Long Wu >>>>> No need add your colleagues unless they "reviwed-by" through >>>>> email-list. >>>>> >>>> Hi Connor, >>>> >>>> This is done time to time, if code is already internally reviewed, send >>>> review/ack tags within the patch, to reduce noise in the mail list. >>> This is the reason why patches from us usually have 1 or 2 R-b tags when >>> we post to the list. We have an internal review and CI pipeline we run >>> patches thru to reduce the noise at the list and to not waste upstream >>> review resources. >>> >>> We follow the DPDK workflow internally before we submit patches to the >>> public mailing list. I hope we can continue to do so and add R-b tags, >>> as they represent real effort by the developers. >> Actually,  this is an interesting story. >> The reason why I said so is I met same circumstances a few years ago. >> Then I sent one patch with R-b tags which added internally by my >> colleagues. >> >> Someone from mail-list said this was not right.  From then on, every time I >> send patches, I will delete R-b tags and send to mail-list. >> > For a driver, vendor and maintainers are experts and probably internal > reviews are good enough. Most of the times details are not interesting > to the rest of the community. Ok, I see, thanks Ferruh. > But for code that impact multiple vendors, like libraries, it is good to > have public reviews to share reasoning and updates and record them for > future. > > Sometimes for this code that impact multiple vendor, if the author and > maintainer are from same company, we receive a patch with maintainer's > ack with it. > This raises questions on how much it is reviewed, how many internal > version it went through 1 or 11, or what was the design decision > reasoning etc.. If these concerns felt somehow, explicit acks from > maintainer requested time to time. > > Or for me, some obvious mistakes in patch, with maintainer's ack already > embedded in it raises similar concerns and I request explicit ack. > > But technically there is nothing preventing ack to be embedded into > patch itself. >