Re: [PATCH v2 20/20] libnd, nd_acpi, nd_blk: driver for BLK-mode access persistent memory

[Andy Lutomirski]

On Tue, Apr 28, 2015 at 3:30 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
> On Tue, Apr 28, 2015 at 2:10 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>> On Tue, Apr 28, 2015 at 11:26 AM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
>>> From: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx>
>>>
>>> The libnd implementation handles allocating dimm address space (DPA)
>>> between PMEM and BLK mode interfaces.  After DPA has been allocated from
>>> a BLK-region to a BLK-namespace the nd_blk driver attaches to handle I/O
>>> as a struct bio based block device. Unlike PMEM, BLK is required to
>>> handle platform specific details like mmio register formats and memory
>>> controller interleave.  For this reason the libnd generic nd_blk driver
>>> calls back into the bus provider to carry out the I/O.
>>>
>>> This initial implementation handles the BLK interface defined by the
>>> ACPI 6 NFIT [1] and the NVDIMM DSM Interface Example [2] composed from
>>> DCR (dimm control region), BDW (block data window), IDT (interleave
>>> descriptor) NFIT structures and the hardware register format.
>>> [1]: http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
>>> [2]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
>>>
>>> Cc: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
>>> Cc: Boaz Harrosh <boaz@xxxxxxxxxxxxx>
>>> Cc: H. Peter Anvin <hpa@xxxxxxxxx>
>>> Cc: Jens Axboe <axboe@xxxxxx>
>>> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
>>> Cc: Christoph Hellwig <hch@xxxxxx>
>>> Signed-off-by: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx>
>>> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
>>> ---
>>>  drivers/block/nd/Kconfig          |   12 +
>>>  drivers/block/nd/Makefile         |    3
>>>  drivers/block/nd/acpi.c           |  422 +++++++++++++++++++++++++++++++++++--
>>>  drivers/block/nd/acpi_nfit.h      |   47 ++++
>>>  drivers/block/nd/blk.c            |  264 +++++++++++++++++++++++
>>>  drivers/block/nd/libnd.h          |   11 +
>>>  drivers/block/nd/namespace_devs.c |   47 ++++
>>>  drivers/block/nd/nd-private.h     |    3
>>>  drivers/block/nd/nd.h             |   16 +
>>>  drivers/block/nd/region.c         |    8 +
>>>  drivers/block/nd/region_devs.c    |   65 +++++-
>>>  drivers/block/nd/test/nfit.c      |   29 +++
>>>  drivers/block/nd/test/nfit_test.h |    2
>>>  13 files changed, 891 insertions(+), 38 deletions(-)
>>>  create mode 100644 drivers/block/nd/blk.c
>>>
>>> diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
>>> index 612bf2b14283..bac4290129fc 100644
>>> --- a/drivers/block/nd/Kconfig
>>> +++ b/drivers/block/nd/Kconfig
>>> @@ -95,6 +95,18 @@ config BLK_DEV_PMEM
>>>
>>>           Say Y if you want to use a NVDIMM described by ACPI, E820, etc...
>>>
>>> +config ND_BLK
>>> +       tristate "BLK: Block data window (aperture) device support"
>>> +       depends on LIBND
>>> +       default ND_ACPI
>>> +       help
>>> +         This driver performs I/O using a set of mmio windows on a
>>> +         dimm.  The set of apertures will all access the one DIMM.
>>> +         Multiple windows allow multiple threads to have a different
>>> +         portions of the dimm open at one time.
>>> +
>>> +         Say Y if you want to use a NVDIMM with BLK-mode capability
>>> +
>>
>> This describes how it works, not what it is.  How about:
>>
>> This driver exposes NVDIMM BLK regions as block devices.  BLK regions
>> are regions of NVDIMM storage that are sector-addressable, not
>> byte-addressible, and do not support DAX.
>
> They *are* byte-addressable albeit through an indirection window.  The
> indirection windows are too small for DAX to be a viable access mode.

Right, I was assuming incorrectly that the sector-atomic thing was a
necessary part of BLK, or at least of this implementation.

Anyway, I think my point stands: let's describe what these drivers do
from a user's perspective, not how they work.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/