[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d35569df-e0e0-5ea7-9aeb-7ffaeef04b14@linux.ibm.com>
Date: Wed, 5 Jan 2022 20:13:23 +0100
From: Karsten Graul <kgraul@...ux.ibm.com>
To: "D. Wythe" <alibuda@...ux.alibaba.com>
Cc: dust.li@...ux.alibaba.com, kuba@...nel.org, davem@...emloft.net,
netdev@...r.kernel.org, linux-s390@...r.kernel.org,
linux-rdma@...r.kernel.org
Subject: Re: [PATCH net-next v2] net/smc: Reduce overflow of smc clcsock
listen queue
On 05/01/2022 16:06, D. Wythe wrote:
> LGTM. Fallback makes the restrictions on SMC dangling
> connections more meaningful to me, compared to dropping them.
>
> Overall, i see there are two scenario.
>
> 1. Drop the overflow connections limited by userspace application
> accept.
>
> 2. Fallback the overflow connections limited by the heavy process of
> current SMC handshake. ( We can also control its behavior through
> sysctl.)
>
I vote for (2) which makes the behavior from user space applications point of view more like TCP.
One comment to sysctl: our current approach is to add new switches to the existing
netlink interface which can be used with the smc-tools package (or own implementations of course).
Is this prereq problematic in your environment?
We tried to avoid more sysctls and the netlink interface keeps use more flexible.
Powered by blists - more mailing lists