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

[humin (Q)]

在 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 <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.
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.
>