From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH 2/3] nvme: introduce max_segments controller attribute
Date: Thu, 17 Aug 2017 09:40:34 +0200 [thread overview]
Message-ID: <20170817074034.GC24372@lst.de> (raw)
In-Reply-To: <bd77f99f-67c9-b648-1b93-43d3a6feb414@grimberg.me>
On Wed, Aug 16, 2017@10:04:09PM +0300, Sagi Grimberg wrote:
>
>>> Why is this needed with patches 1,3 applied?
>>>
>>> We set the page_size and we set max_hw_sectors accordingly.
>>
>> We didn't touch the ctrl->page_size. It's always 4k (the target checks it).
>> This may cause max_segments to be bigger than hw limitation (in PPC for
>> example).
>
> Right, got confused for a second, but why shouldn't we modify the
> ctrl page_size in rdma? Its not really a controller attribute, but
> rather the local HCA attribute really.
But the controller needs to support it, and NVMe controllers are
only required to support a 4k page size, the rest is optional.
> Or, we could simply fix nvme-core to take PAGE_SIZE if supported by
> the ctrl and fallback to 4k otherwise.
For PCIe (before fabrics existed) we used to do that, but we changed
it for ppc64 in this commit:
c5c9f25b98 ("NVMe: default to 4k device page size")
next prev parent reply other threads:[~2017-08-17 7:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 10:20 [PATCH 1/3] nvme: add virt boundary per ctrl Max Gurtovoy
2017-08-16 10:20 ` [PATCH 2/3] nvme: introduce max_segments controller attribute Max Gurtovoy
2017-08-16 13:29 ` Sagi Grimberg
2017-08-16 14:35 ` Max Gurtovoy
2017-08-16 19:04 ` Sagi Grimberg
2017-08-17 7:40 ` Christoph Hellwig [this message]
2017-08-20 6:35 ` Sagi Grimberg
2017-08-22 6:32 ` Christoph Hellwig
2017-08-22 9:36 ` Max Gurtovoy
2017-08-22 9:40 ` Christoph Hellwig
2017-08-16 10:21 ` [PATCH 3/3] nvme-rdma: fix virtual boundary calculation Max Gurtovoy
2017-08-21 22:45 ` [PATCH 1/3] nvme: add virt boundary per ctrl James Smart
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=20170817074034.GC24372@lst.de \
--to=hch@lst.de \
/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