[PATCH v3] net/bonding: fix bond startup failure when NUMA is -1

[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 <zerun.fu at corigine.com>
>>>>>
>>>>> 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 at dpdk.org
>>>>>
>>>>> Signed-off-by: Zerun Fu <zerun.fu at corigine.com>
>>>>> Reviewed-by: Peng Zhang <peng.zhang at corigine.com>
>>>>> Reviewed-by: Chaoyong He <chaoyong.he at corigine.com>
>>>>> Reviewed-by: Long Wu <long.wu at corigine.com>
>>>> 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.

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.