[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWzfovS+kh=UsJZxNvN-_eypav+Df+NppPHt8FPPOSipw@mail.gmail.com>
Date: Mon, 29 Aug 2016 16:20:43 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Keith Busch <keith.busch@...el.com>
Cc: Andy Lutomirski <luto@...nel.org>, Jens Axboe <axboe@...com>,
linux-nvme@...ts.infradead.org, Christoph Hellwig <hch@....de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] nvme: Pass pointers, not dma addresses, to nvme_get/set_features()
On Mon, Aug 29, 2016 at 9:27 AM, Keith Busch <keith.busch@...el.com> wrote:
> On Mon, Aug 29, 2016 at 02:25:45AM -0700, Andy Lutomirski wrote:
>> + /*
>> + * A controller "page" may be bigger than a Linux page, but we can
>> + * be conservative here.
>> + */
>
> It is the actually other way around: the Linux page may be larger than the
> controller's. We currently use the smallest possible controller page (4k)
> regardless of the host's size due to limitations discovering the CPU's
> DMA alignment. PPC was the first to encounter this problem with NVMe.
The "Set Features" command (section 5.15) Figure 103 says:
If using PRPs, this field shall not be a pointer to a PRP List as the
data buffer may not cross more than one page boundary. If no data
structure is used as part of the specified feature, then this field is
not used.
Does the Linux driver use PRPs? Do we need to worry about kmalloc
returning a buffer that spans a 4k boundary but does not span a Linux
page boundary?
--Andy
Powered by blists - more mailing lists