public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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