From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Håkon Bugge" <haakon.bugge@oracle.com>
Cc: Doug Ledford <dledford@redhat.com>,
Leon Romanovsky <leon@kernel.org>,
Parav Pandit <parav@mellanox.com>,
Steve Wise <swise@opengridcomputing.com>,
OFED mailing list <linux-rdma@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] RDMA/cma: Make CM response timeout and # CM retries configurable
Date: Thu, 13 Jun 2019 14:23:55 -0300 [thread overview]
Message-ID: <20190613172355.GF22901@ziepe.ca> (raw)
In-Reply-To: <67B4F337-4C3A-4193-B1EF-42FD4765CBB7@oracle.com>
On Thu, Jun 13, 2019 at 06:58:30PM +0200, Håkon Bugge wrote:
> If you refer to the backlog parameter in rdma_listen(), I cannot see
> it being used at all for IB.
>
> For CX-3, which is paravirtualized wrt. MAD packets, it is the proxy
> UD receive queue length for the PF driver that can be construed as a
> backlog.
No, in IB you can drop UD packets if your RQ is full - so the proxy RQ
is really part of the overall RQ on QP1.
The backlog starts once packets are taken off the RQ and begin the
connection accept processing.
> Customer configures #VMs and different workload may lead to way
> different number of CM connections. The proxying of MAD packet
> through the PF driver has a finite packet rate. With 64 VMs, 10.000
> QPs on each, all going down due to a switch failing or similar, you
> have 640.000 DREQs to be sent, and with the finite packet rate of MA
> packets through the PF, this takes more than the current CM
> timeout. And then you re-transmit and increase the burden of the PF
> proxying.
I feel like the performance of all this proxying is too low to support
such a large work load :(
Can it be improved?
Jason
next prev parent reply other threads:[~2019-06-13 17:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-26 7:57 [PATCH v2] RDMA/cma: Make CM response timeout and # CM retries configurable Håkon Bugge
2019-06-13 14:25 ` Doug Ledford
2019-06-13 15:28 ` Bart Van Assche
2019-06-13 16:32 ` Doug Ledford
2019-06-13 16:58 ` Håkon Bugge
2019-06-13 17:23 ` Jason Gunthorpe [this message]
2019-06-13 17:39 ` Håkon Bugge
2019-06-13 23:46 ` Jason Gunthorpe
2019-06-13 20:25 ` Doug Ledford
2019-06-14 5:44 ` Håkon Bugge
2019-10-29 12:59 ` Dag Moxnes
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=20190613172355.GF22901@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=dledford@redhat.com \
--cc=haakon.bugge@oracle.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=parav@mellanox.com \
--cc=swise@opengridcomputing.com \
/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