From: Walker, Benjamin <benjamin.walker at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] RDMA Queue Pair
Date: Fri, 30 Jun 2017 16:07:41 +0000 [thread overview]
Message-ID: <1498838859.3097.17.camel@intel.com> (raw)
In-Reply-To: A8259ED9-8802-44CB-9E23-BBC464B455FA@cloudsimple.com
[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]
On Fri, 2017-06-30 at 18:09 +0530, Kumaraparameshwaran Rathnavel wrote:
> Hi All,
>
> I would like to get few pointers on how the RDMA is used in NVMf Target . The
> below statement decides the value of Qdepth of NVMf Qpair.
> nvmf_min(max_rw_depth, addr->attr.max_qp_rd_atom and anything more than this
> will be Queued irrespective of what the upper layer has the Queue depth as.
>
> And the value for attr.max_qp_rd_atom is got by Querying the device. I see
> that ideally in most of NICs the value is 16. So does this mean that in a
> Queue pair there cannot be more RDMA requests than this value.
The queue depth calculations for RDMA are actually quite involved. RDMA has four
base operations - send, recv, read, and write - and the available queue depth
for read/write is different than for send/recv. RDMA send/recv operations are
used to send the NVMe commands and responses, while the RDMA read/write
operations are used to transfer data. It's just the read/write limit that is
usually 16 per queue pair, limited by the NIC capabilities. The send/recv limit
is much higher, with the NIC supporting queues of anywhere from 1024 to 64k
depth.
Therefore, we report typically 128 queue depth available and the target will
gather up to 128 total commands at a time. If the commands are all NVMe reads,
for example, the target will queue up the full 128 queue depth to the backing
SSD. However, it can only perform 16 simultaneous RDMA read or writes per queue
pair, so often commands will get queued in the RDMA layer waiting on that limit.
>
> Please correct me if I am wrong.
>
> Thanking You,
> Param.
>
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3274 bytes --]
next reply other threads:[~2017-06-30 16:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-30 16:07 Walker, Benjamin [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-07-01 6:38 [SPDK] RDMA Queue Pair Kumaraparameshwaran Rathnavel
2017-06-30 12:39 Kumaraparameshwaran Rathnavel
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=1498838859.3097.17.camel@intel.com \
--to=spdk@lists.01.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