Received: by 10.223.185.116 with SMTP id b49csp6782723wrg; Wed, 28 Feb 2018 15:43:20 -0800 (PST) X-Google-Smtp-Source: AG47ELtYnMGEDD+CPFlgYdQBcDQUZ5PlFCS9qZ//+9hloUDttPsqYParwGWqhM60N0Hj9bFFQXs6 X-Received: by 2002:a17:902:bc3:: with SMTP id 61-v6mr4905859plr.398.1519861400113; Wed, 28 Feb 2018 15:43:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519861400; cv=none; d=google.com; s=arc-20160816; b=xUSko3KNs7ArGdQxN1tP4SJvxBuZsitDq9GR44e+X1g8LljOL62EPcAnw1mV/wmj68 Z1UFaz2C7RcgqrByeGejEWB1aC3EH0WGsv1zsjX6vsMXw3AKfJHd4UnER7AkLKHNd38O 4P7OqqbV9EYi5+6cmwlEaksPnag5QJmMBK0YW0jXt4+9wuL+gzElrPLGq7z/7ef+DqJp +hrYFzmL703FOs3q2573edAoSgeHWXmXEnOWedqQrIRkier1UlR6DjJ0GQ3W4TS4Do+o jfpvl8iMXLHrbTTBErRBzrC6w/By9YGjO5jkWX/YOcJ+dM31/BZJSVQlkCIB4TTPryEX OxuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:message-id:date:cc:to:from :arc-authentication-results; bh=Y2LPhu0mqma15HhzX7Pif/XCEoL3ChmVPUJb16kUmn0=; b=Th5kcghDjaNolX1M2QcLgwE5usc75m4z1nlTpAzfeTuJB0Ql7g0a9yPaW+Tk2j2KJg 43IzwV13WtFml75KcsWve2Y0Ebyrps7LjF6JF0uGx2438kUBwEczGfX+mLblbVcB6XMM u3wjUdU5LYgKkkCSdCkQ7OjMVz8PKUL45ktgclrjzB4e1n3xef+D/7aCyltPZpF08GtA z+mJ4YCZQ704XC9YmbU6AKn68fKK8NnquSOR0E5BILiYBemf2WzVhGmG1qiWKoUyteBx /qLdAXKOiBIC5gvbWRfsrmHCHI0pILL7RMX5wU6+9pgHlYdA53SMeJ1lCZPOczwOclVG Qo1g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s23si1944450pfm.392.2018.02.28.15.43.05; Wed, 28 Feb 2018 15:43:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965232AbeB1Xl1 (ORCPT + 99 others); Wed, 28 Feb 2018 18:41:27 -0500 Received: from ale.deltatee.com ([207.54.116.67]:60164 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965054AbeB1XkZ (ORCPT ); Wed, 28 Feb 2018 18:40:25 -0500 Received: from cgy1-donard.priv.deltatee.com ([172.16.1.31]) by ale.deltatee.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1erBKc-0003TP-OJ; Wed, 28 Feb 2018 16:40:19 -0700 Received: from gunthorp by cgy1-donard.priv.deltatee.com with local (Exim 4.89) (envelope-from ) id 1erBKZ-0005V4-2Y; Wed, 28 Feb 2018 16:40:15 -0700 From: Logan Gunthorpe To: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org, linux-nvdimm@lists.01.org, linux-block@vger.kernel.org Cc: Stephen Bates , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , Bjorn Helgaas , Jason Gunthorpe , Max Gurtovoy , Dan Williams , =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= , Benjamin Herrenschmidt , Alex Williamson , Logan Gunthorpe Date: Wed, 28 Feb 2018 16:39:56 -0700 Message-Id: <20180228234006.21093-1-logang@deltatee.com> X-Mailer: git-send-email 2.11.0 X-SA-Exim-Connect-IP: 172.16.1.31 X-SA-Exim-Rcpt-To: linux-nvme@lists.infradead.org, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-rdma@vger.kernel.org, linux-block@vger.kernel.org, sbates@raithlin.com, hch@lst.de, axboe@kernel.dk, sagi@grimberg.me, bhelgaas@google.com, jgg@mellanox.com, maxg@mellanox.com, keith.busch@intel.com, dan.j.williams@intel.com, benh@kernel.crashing.org, jglisse@redhat.com, alex.williamson@redhat.com, logang@deltatee.com X-SA-Exim-Mail-From: gunthorp@deltatee.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on ale.deltatee.com X-Spam-Level: X-Spam-Status: No, score=-6.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, MYRULES_NO_TEXT,T_RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 Subject: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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, we've made the following changes based on feedback: * Renamed everything to 'p2pdma' per the suggestion from Bjorn as well as a bunch of cleanup and spelling fixes he pointed out in the last series. * To address Alex's ACS concerns, we change to a simpler method of just disabling ACS behind switches for any kernel that has CONFIG_PCI_P2PDMA. * We also reject using devices that employ 'dma_virt_ops' which should fairly simply handle Jason's concerns that this work might break with the HFI, QIB and rxe drivers that use the virtual ops to implement their own special DMA operations. Thanks, Logan -- This is a continuation of our work to enable using Peer-to-Peer PCI memory in NVMe fabrics targets. Many thanks go to Christoph Hellwig who provided valuable feedback to get these patches to where they are today. The concept here is to use memory that's exposed on a PCI BAR as data buffers in the NVME target code such that data can be transferred from an RDMA NIC to the special memory and then directly to an NVMe device avoiding system memory entirely. The upside of this is better QoS for applications running on the CPU utilizing memory and lower PCI bandwidth required to the CPU (such that systems could be designed with fewer lanes connected to the CPU). However, presently, the trade-off is currently a reduction in overall throughput. (Largely due to hardware issues that would certainly improve in the future). Due to these trade-offs we've designed the system to only enable using the PCI memory in cases where the NIC, NVMe devices and memory are all behind the same PCI switch. This will mean many setups that could likely work well will not be supported so that we can be more confident it will work and not place any responsibility on the user to understand their topology. (We chose to go this route based on feedback we received at the last LSF). Future work may enable these transfers behind a fabric of PCI switches or perhaps using a white list of known good root complexes. In order to enable this functionality, we introduce a few new PCI functions such that a driver can register P2P memory with the system. Struct pages are created for this memory using devm_memremap_pages() and the PCI bus offset is stored in the corresponding pagemap structure. Another set of functions allow a client driver to create a list of client devices that will be used in a given P2P transactions and then use that list to find any P2P memory that is supported by all the client devices. This list is then also used to selectively disable the ACS bits for the downstream ports behind these devices. In the block layer, we also introduce a P2P request flag to indicate a given request targets P2P memory as well as a flag for a request queue to indicate a given queue supports targeting P2P memory. P2P requests will only be accepted by queues that support it. Also, P2P requests are marked to not be merged seeing a non-homogenous request would complicate the DMA mapping requirements. In the PCI NVMe driver, we modify the existing CMB support to utilize the new PCI P2P memory infrastructure and also add support for P2P memory in its request queue. When a P2P request is received it uses the pci_p2pmem_map_sg() function which applies the necessary transformation to get the corrent pci_bus_addr_t for the DMA transactions. In the RDMA core, we also adjust rdma_rw_ctx_init() and rdma_rw_ctx_destroy() to take a flags argument which indicates whether to use the PCI P2P mapping functions or not. Finally, in the NVMe fabrics target port we introduce a new configuration boolean: 'allow_p2pmem'. When set, the port will attempt to find P2P memory supported by the RDMA NIC and all namespaces. If supported memory is found, it will be used in all IO transfers. And if a port is using P2P memory, adding new namespaces that are not supported by that memory will fail. Logan Gunthorpe (10): PCI/P2PDMA: Support peer to peer memory PCI/P2PDMA: Add sysfs group to display p2pmem stats PCI/P2PDMA: Add PCI p2pmem dma mappings to adjust the bus offset PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches block: Introduce PCI P2P flags for request and request queue IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]() nvme-pci: Use PCI p2pmem subsystem to manage the CMB nvme-pci: Add support for P2P memory in requests nvme-pci: Add a quirk for a pseudo CMB nvmet: Optionally use PCI P2P memory Documentation/ABI/testing/sysfs-bus-pci | 25 ++ block/blk-core.c | 3 + drivers/infiniband/core/rw.c | 21 +- drivers/infiniband/ulp/isert/ib_isert.c | 5 +- drivers/infiniband/ulp/srpt/ib_srpt.c | 7 +- drivers/nvme/host/core.c | 4 + drivers/nvme/host/nvme.h | 8 + drivers/nvme/host/pci.c | 118 ++++-- drivers/nvme/target/configfs.c | 29 ++ drivers/nvme/target/core.c | 95 ++++- drivers/nvme/target/io-cmd.c | 3 + drivers/nvme/target/nvmet.h | 10 + drivers/nvme/target/rdma.c | 43 +- drivers/pci/Kconfig | 20 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 713 ++++++++++++++++++++++++++++++++ drivers/pci/pci.c | 4 + include/linux/blk_types.h | 18 +- include/linux/blkdev.h | 3 + include/linux/memremap.h | 19 + include/linux/pci-p2pdma.h | 105 +++++ include/linux/pci.h | 4 + include/rdma/rw.h | 7 +- net/sunrpc/xprtrdma/svc_rdma_rw.c | 6 +- 24 files changed, 1204 insertions(+), 67 deletions(-) create mode 100644 drivers/pci/p2pdma.c create mode 100644 include/linux/pci-p2pdma.h -- 2.11.0