From: "dust.li" <dust.li@linux.alibaba.com>
To: Guangguan Wang <guangguan.wang@linux.alibaba.com>,
kgraul@linux.ibm.com, davem@davemloft.net, kuba@kernel.org
Cc: linux-s390@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH net-next] net/smc: Introduce receive queue flow control support
Date: Thu, 20 Jan 2022 17:51:30 +0800 [thread overview]
Message-ID: <20220120095130.GB41938@linux.alibaba.com> (raw)
In-Reply-To: <20220120065140.5385-1-guangguan.wang@linux.alibaba.com>
On Thu, Jan 20, 2022 at 02:51:40PM +0800, Guangguan Wang wrote:
>This implement rq flow control in smc-r link layer. QPs
>communicating without rq flow control, in the previous
>version, may result in RNR (reveive not ready) error, which
>means when sq sends a message to the remote qp, but the
>remote qp's rq has no valid rq entities to receive the message.
>In RNR condition, the rdma transport layer may retransmit
>the messages again and again until the rq has any entities,
>which may lower the performance, especially in heavy traffic.
>Using credits to do rq flow control can avoid the occurrence
>of RNR.
I'm wondering if SRQ can be used to solve this problem ?
One of my concern on credit-base flow control is if the RTT is
a bit longer, we may have to wait RTT/2 for peer to grant us credit
before we can really send more data. That may decrease the maximium
bandwidth we can achive in this case.
next prev parent reply other threads:[~2022-01-20 9:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 6:51 [RFC PATCH net-next] net/smc: Introduce receive queue flow control support Guangguan Wang
2022-01-20 8:24 ` Leon Romanovsky
2022-01-20 9:20 ` Guangguan Wang
2022-01-20 9:51 ` dust.li [this message]
2022-01-21 16:21 ` Guangguan Wang
2022-01-20 11:03 ` Karsten Graul
2022-01-21 16:36 ` Guangguan Wang
2022-01-20 14:22 ` Tony Lu
2022-01-21 16:48 ` Guangguan Wang
2022-01-25 9:42 ` Stefan Raspl
2022-01-29 3:43 ` Guangguan Wang
2022-01-29 4:24 ` Tony Lu
2022-01-31 12:56 ` 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=20220120095130.GB41938@linux.alibaba.com \
--to=dust.li@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=guangguan.wang@linux.alibaba.com \
--cc=kgraul@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).