On Wed, Jan 05, 2022 at 12:40:49PM +0800, D. Wythe wrote: >Hi, > >Since we are trying to use the backlog parameter to limit smc dangling >connections, it's seems there's no difference from increasing the >backlog parameter for the TCP listen socket, user space Application can >simply avoid the 10K connections problem through that. > >If so, this patch looks redundant to me. Look forward to your advise. I think increase backlog in the userspace application is not a good idea. AFAIU, SMC tries to behave the same like TCP in the socket layer, asking the APP to increase the backlog breaks this principle. In the TCP case, the backlog usually don't get overflow if the APP calls accept() fast enough. For SMC, it should also accept() fast enough to make sure the backlog of the CLC socket won't overflow. But it didn't because smc_hs_wq is busy hence TCP dropped the SYN. From the APP's perspective of view, he is fast enough, but the kernel didn't give him the chance. I think this behaves different from TCP. I'm thinking maybe we can actively fall back to TCP in this case ? Not sure if this is a good idea.
