linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sagi@grimberg.me (Sagi Grimberg)
Subject: [PATCH RFC] nvme-rdma: support devices with queue size < 32
Date: Tue, 28 Mar 2017 14:30:14 +0300	[thread overview]
Message-ID: <8dc0414f-be90-ee30-0f66-8cee26c4c2aa@grimberg.me> (raw)
In-Reply-To: <1180136633.325075447.1490700022740.JavaMail.zimbra@kalray.eu>


>> Maybe it'll be better if we do:
>>
>> static inline bool queue_sig_limit(struct nvme_rdma_queue *queue)
>> {
>> 	return (++queue->sig_count % (queue->queue_size / 2)) == 0;
>> }
>>
>> And lose the hard-coded 32 entirely. Care to test that?
>
> Hello Sigi,
> I agree with you, we've found a setup where the signalling every queue
> depth is not enough and we're testing the division by two that seems
> to work fine till now.
>
> In your version in case of queue length > 32 the notifications would
> be sent less often that they are now. I'm wondering if it will have
> impact on performance and internal card buffering (it seems that
> Mellanox buffers are ~100 elements). Wouldn't it create issues?
>
> I'd like see the magic constant removed. From what I can see we
> need to have something not exceeding send buffer of the card but
> also not lower than the queue depth. What do you think?

I'm not sure what buffering is needed from the device at all in this
case, the device is simply expected to avoid signaling completions.

Mellanox folks, any idea where is this limitation coming from?
Do we need a device capability for it?

  reply	other threads:[~2017-03-28 11:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-23  9:04 [PATCH RFC] nvme-rdma: support devices with queue size < 32 Marta Rybczynska
2017-03-23  9:24 ` Marta Rybczynska
2017-03-23 14:00 ` Christoph Hellwig
2017-03-23 14:36   ` Marta Rybczynska
2017-03-28 11:09     ` Sagi Grimberg
2017-03-28 11:20       ` Marta Rybczynska
2017-03-28 11:30         ` Sagi Grimberg [this message]
2017-03-29  9:36           ` Marta Rybczynska
2017-03-29 13:29           ` Jason Gunthorpe
2017-03-29 15:47             ` Sagi Grimberg
2017-03-29 16:27               ` Jason Gunthorpe
2017-03-29 16:39                 ` Sagi Grimberg
2017-03-29 16:44                   ` Doug Ledford
2017-03-29 16:47                     ` Doug Ledford
2017-03-29 16:59                       ` Sagi Grimberg
2017-03-29 22:19                         ` Jason Gunthorpe
2017-03-30 14:23                         ` Marta Rybczynska
2017-04-06 12:29                           ` Marta Rybczynska
2017-04-06 13:02                             ` Leon Romanovsky
2017-04-07 13:31                               ` Marta Rybczynska
2017-04-09 12:31                                 ` Sagi Grimberg
2017-04-10 11:29                                   ` Marta Rybczynska

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=8dc0414f-be90-ee30-0f66-8cee26c4c2aa@grimberg.me \
    --to=sagi@grimberg.me \
    /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).