[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <de0baa92-417c-475a-a342-9041f8fb5b8e@linux.ibm.com>
Date: Mon, 6 Oct 2025 11:25:22 +0530
From: Mahanta Jambigi <mjambigi@...ux.ibm.com>
To: dust.li@...ux.alibaba.com, Halil Pasic <pasic@...ux.ibm.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
Jonathan Corbet <corbet@....net>,
"D. Wythe" <alibuda@...ux.alibaba.com>,
Sidraya Jayagond <sidraya@...ux.ibm.com>,
Wenjia Zhang
<wenjia@...ux.ibm.com>,
Tony Lu <tonylu@...ux.alibaba.com>, Wen Gu <guwen@...ux.alibaba.com>,
Guangguan Wang <guangguan.wang@...ux.alibaba.com>,
netdev@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
linux-s390@...r.kernel.org
Subject: Re: [PATCH net-next v5 2/2] net/smc: handle -ENOMEM from
smc_wr_alloc_link_mem gracefully
On 29/09/25 7:20 am, Dust Li wrote:
>> diff --git a/net/smc/smc_core.h b/net/smc/smc_core.h
>> index 8d06c8bb14e9..5c18f08a4c8a 100644
>> --- a/net/smc/smc_core.h
>> +++ b/net/smc/smc_core.h
>> @@ -175,6 +175,8 @@ struct smc_link {
>> struct completion llc_testlink_resp; /* wait for rx of testlink */
>> int llc_testlink_time; /* testlink interval */
>> atomic_t conn_cnt; /* connections on this link */
>> + u16 max_send_wr;
>> + u16 max_recv_wr;
>
> Here, you've moved max_send_wr/max_recv_wr from the link group to individual links.
> This means we can now have different max_send_wr/max_recv_wr values on two
> different links within the same link group.
> Since in Alibaba we doesn't use multi-link configurations, we haven't tested
Does Alibaba always use a single RoCE device for SMC-R? In that case how
redundancy is achieved if that link goes down?
> this scenario. Have you tested the link-down handling process in a multi-link
> setup?
I did test this after you query & don't see any issues. As Halil
mentioned in worst case scenario one link might perform lesser than the
other, that too if the kcalloc() failed for that link in
smc_wr_alloc_link_mem() & succeeded in subsequent request with reduced
max_send_wr/max_recv_wr size(half).
> Otherwise, the patch looks good to me.
>
> Best regards,
> Dust
Powered by blists - more mailing lists