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 31C2D42D0A for ; Tue, 20 Jun 2023 16:20:02 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2D68740DDA; Tue, 20 Jun 2023 16:20:02 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 813EA400D6; Tue, 20 Jun 2023 16:20:01 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 10F825C02C0; Tue, 20 Jun 2023 10:19:59 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 20 Jun 2023 10:19:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1687270799; x=1687357199; bh=7dMe3Yo/hpE3xlfc9AxxqmxDGEUvptd86av Pa0SwE2g=; b=qPKQ0Vp/cDWHUDE7kVBIg870bBiAXWYV8dlIJRDw2Q+y4+06a/2 GCPpWdhFbWLdLgVHVocbzj9uZWdhzgdurGX7XdLWcX1qvD02qYNp6HdLae0HTfhN EENUIrFaKQGlv9mjNyYyG6cV7ovn+bV8fyRQKEXz0kKAgxKogJZC7Jlr/rZwYN1E GRH5gXwjqdoyko0lccKgmDx+/FoBGQNotClyjuYgERyxMhUAa2fKgRKen49Ds3T9 WvgepwreOyzvfwYMwidIjVen9hi6pyG/+fzn9t0kuplQ4tdQZT+RGoaipmnJ9tCw wv1fjDgRJRM7jkhOCsmpMe2eNkUBbR7k3yQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1687270799; x=1687357199; bh=7dMe3Yo/hpE3xlfc9AxxqmxDGEUvptd86av Pa0SwE2g=; b=KFt2ssw3/PfBIP/ShDh2NBHIew0aezYKMxZ8sUgk62mYANPGvtb Alrc6uFvaZepghakkhJlFEw2eE7ucVJQjEa6vTyn2h7+MlNLnHVlqC29epzlaKw1 IY49mSxPppiMNKhL/lrJs4fDH/FGq47qRmdZjC28k9EomX7vvQinLQ8Drv1gLwH/ WK2NucyrLLvEbq+wGjj8tLFPafGtvQmoZQFj4DWQ7h7sq3VsC8fYq9QdPoMCL+T3 p0jW81EvwRlrAZUsjWvXGapJ8g4YiWPK5pzQwnVNh+vPKvQ0Xwi/PLgYWWQGfmEB 2TQdk0io1KCAhXx9jOFo48lSIFe3jEvDl3g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgeefhedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdei uddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 20 Jun 2023 10:19:57 -0400 (EDT) From: Thomas Monjalon To: "humin (Q)" , Niklas =?ISO-8859-1?Q?S=F6derlund?= , Ferruh Yigit Cc: Chaoyong He , dev@dpdk.org, oss-drivers@corigine.com, Zerun Fu , stable@dpdk.org, Peng Zhang , Long Wu , David Marchand Subject: Re: [PATCH v3] net/bonding: fix bond startup failure when NUMA is -1 Date: Tue, 20 Jun 2023 16:19:55 +0200 Message-ID: <1761107.VLH7GnMWUR@thomas> In-Reply-To: <0cda2d4a-1deb-9024-9578-de98082c6ffc@amd.com> References: <20230616071558.1278520-1-chaoyong.he@corigine.com> <5eceb17a-adf4-11e3-4274-0d6e111b091d@huawei.com> <0cda2d4a-1deb-9024-9578-de98082c6ffc@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 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 20/06/2023 16:10, Ferruh Yigit: > On 6/20/2023 2:15 PM, humin (Q) wrote: > > Hi, Niklas, Ferruh, > >=20 > > =E5=9C=A8 2023/6/20 19:03, Niklas S=C3=B6derlund =E5=86=99=E9=81=93: > >> 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, > >>>> > >>>> =E5=9C=A8 2023/6/16 15:20, Chaoyong He =E5=86=99=E9=81=93: > >>>>> 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 architectur= e, > >>>>> 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, se= nd > >>> 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 wh= en > >> 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. > >=20 > > 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. > >=20 > > Someone from mail-list said this was not right. From then on, every ti= me I > > send patches, I will delete R-b tags and send to mail-list. > >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Or for me, some obvious mistakes in patch, with maintainer's ack already > embedded in it raises similar concerns and I request explicit ack. >=20 > But technically there is nothing preventing ack to be embedded into > patch itself. Yes If there is an internal review, you can embed the tag. The decision of what is enough for a patch to be merged is the role of the tree maintainer. The component maintainer must make sure that the patches are well reviewed, and the tree maintainer does a last check of trust & quality.