Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > > Hi Everyone, > > > So Oliver (CC) was having issues getting any of that to work for us. > > The problem is that acccording to him (I didn't double check the latest >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > Hi Everyone, So Oliver (CC) was having issues getting any of that to work for us. The problem is that acccording to him (I didn't double check the latest patches) you effectively hotplug the PCIe memory into the system when creating

Returned mail: see transcript for details

This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely

Re: [PATCH v4 1/3] fs: allow per-device dax status checking for filesystems

Hi Darrick, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc3 next-20180228] [cannot apply to dgc-xfs/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

[PATCH v2 05/10] block: Introduce PCI P2P flags for request and request queue

QUEUE_FLAG_PCI_P2P is introduced meaning a driver's request queue supports targeting P2P memory. REQ_PCI_P2P is introduced to indicate a particular bio request is directed to/from PCI P2P memory. A request with this flag is not accepted unless the corresponding queues have the QUEUE_FLAG_PCI_P2P

[PATCH v2 01/10] PCI/P2PDMA: Support peer to peer memory

Some PCI devices may have memory mapped in a BAR space that's intended for use in Peer-to-Peer transactions. In order to enable such transactions the memory must be registered with ZONE_DEVICE pages so it can be used by DMA interfaces in existing drivers. A kernel interface is provided so that

[PATCH v2 03/10] PCI/P2PDMA: Add PCI p2pmem dma mappings to adjust the bus offset

The DMA address used when mapping PCI P2P memory must be the PCI bus address. Thus, introduce pci_p2pmem_[un]map_sg() to map the correct addresses when using P2P memory. For this, we assume that an SGL passed to these functions contain all p2p memory or no p2p memory. Signed-off-by: Logan

[PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

Hi Everyone, Here's v2 of our series to introduce P2P based copy offload to NVMe fabrics. This version has been rebased onto v4.16-rc3 which already includes Christoph's devpagemap work the previous version was based off as well as a couple of the cleanup patches that were in v1. Additionally,

[PATCH v2 02/10] PCI/P2PDMA: Add sysfs group to display p2pmem stats

Attributes display the total amount of P2P memory, the amount available and whether it is published or not. Signed-off-by: Logan Gunthorpe --- Documentation/ABI/testing/sysfs-bus-pci | 25 + drivers/pci/p2pdma.c| 50

[PATCH v2 08/10] nvme-pci: Add support for P2P memory in requests

For P2P requests we must use the pci_p2pmem_[un]map_sg() functions instead of the dma_map_sg functions. With that, we can then indicate PCI_P2P support in the request queue. For this, we create an NVME_F_PCI_P2P flag which tells the core to set QUEUE_FLAG_PCI_P2P in the request queue.

[PATCH v2 06/10] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

In order to use PCI P2P memory pci_p2pmem_[un]map_sg() functions must be called to map the correct DMA address. To do this, we add a flags variable and the RDMA_RW_CTX_FLAG_PCI_P2P flag. When the flag is specified use the appropriate map function. Signed-off-by: Logan Gunthorpe

[PATCH v2 04/10] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches

For peer-to-peer transactions to work the downstream ports in each switch must not have the ACS flags set. At this time there is no way to dynamically change the flags and update the corresponding IOMMU groups so this is done at enumeration time before the the groups are assigned. This

[PATCH v2 09/10] nvme-pci: Add a quirk for a pseudo CMB

Introduce a quirk to use CMB-like memory on older devices that have an exposed BAR but do not advertise support for using CMBLOC and CMBSIZE. We'd like to use some of these older cards to test P2P memory. Signed-off-by: Logan Gunthorpe --- drivers/nvme/host/nvme.h | 7

[PATCH v2 07/10] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

Register the CMB buffer as p2pmem and use the appropriate allocation functions to create and destroy the IO SQ. If the CMB supports WDS and RDS, publish it for use as p2p memory by other devices. Signed-off-by: Logan Gunthorpe --- drivers/nvme/host/pci.c | 75

[PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

We create a configfs attribute in each nvme-fabrics target port to enable p2p memory use. When enabled, the port will only then use the p2p memory if a p2p memory device can be found which is behind the same switch as the RDMA port and all the block devices in use. If the user enabled it an no

Re: [PATCH 3/5] acpi, nfit: Add function to look up nvdimm device and provide SMBIOS handle

On Wed, Feb 28, 2018 at 10:36:21AM -0700, Ross Zwisler wrote: > Just a quick nit - I think we're supposed to use SPDX license identifiers for > new files? One would think checkpatch would warn about that but nope. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting

Re: [PATCH 3/5] acpi, nfit: Add function to look up nvdimm device and provide SMBIOS handle

On Thu, Feb 22, 2018 at 11:58:09AM -0800, Tony Luck wrote: > EDAC driver needs to look up attributes of NVDIMMs provided in SMBIOS. > > Provide a function that looks up an acpi_nfit_memory_map from a device > handle (node/socket/mc/channel/dimm) and returns the SMBIOS handle. > Also pass back the

Re: [PATCH 0/5] Teach EDAC about non-volatile DIMMs and add partial support to skx_edac

On Wed, Feb 28, 2018 at 5:04 AM, Borislav Petkov wrote: > On Thu, Feb 22, 2018 at 11:58:06AM -0800, Tony Luck wrote: >> This series was posted as RFC and got some review back in December: >> >>https://marc.info/?l=linux-edac=151257213825419=2 >> >> It couldn't go upstream back

Re: [PATCH 0/5] Teach EDAC about non-volatile DIMMs and add partial support to skx_edac

On Thu, Feb 22, 2018 at 11:58:06AM -0800, Tony Luck wrote: > This series was posted as RFC and got some review back in December: > >https://marc.info/?l=linux-edac=151257213825419=2 > > It couldn't go upstream back then because I was waiting for some updates > to the ACPICA headers for NFIT