All of lore.kernel.org
 help / color / mirror / Atom feed
From: "dust.li" <dust.li@linux.alibaba.com>
To: "D. Wythe" <alibuda@linux.alibaba.com>,
	Karsten Graul <kgraul@linux.ibm.com>
Cc: kuba@kernel.org, davem@davemloft.net, netdev@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org
Subject: Re: [PATCH net-next v2] net/smc: Reduce overflow of smc clcsock listen queue
Date: Wed, 5 Jan 2022 16:57:48 +0800	[thread overview]
Message-ID: <20220105085748.GD31579@linux.alibaba.com> (raw)
In-Reply-To: <20220105044049.GA107642@e02h04389.eu6sqa>

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.

  parent reply	other threads:[~2022-01-05  8:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 13:12 [PATCH net-next v2] net/smc: Reduce overflow of smc clcsock listen queue D. Wythe
2022-01-04 13:45 ` Karsten Graul
2022-01-04 16:17   ` D. Wythe
2022-01-05  4:40   ` D. Wythe
2022-01-05  8:28     ` Tony Lu
2022-01-05  8:57     ` dust.li [this message]
2022-01-05 13:17       ` Karsten Graul
2022-01-05 15:06         ` D. Wythe
2022-01-05 19:13           ` Karsten Graul
2022-01-06  7:05             ` Tony Lu
2022-01-13  8:07               ` Karsten Graul
2022-01-13 18:50                 ` Jakub Kicinski
2022-01-20 13:39                 ` Tony Lu
2022-01-20 16:00                   ` Stefan Raspl
2022-01-21  2:47                     ` Tony Lu
2022-02-16 11:46                 ` dust.li
2022-01-06  3:51           ` D. Wythe
2022-01-06  9:54             ` Karsten Graul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220105085748.GD31579@linux.alibaba.com \
    --to=dust.li@linux.alibaba.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=kgraul@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.