Received: by 10.192.165.148 with SMTP id m20csp4545461imm; Tue, 8 May 2018 10:05:41 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr1HC21JH1YC5ZOTcf+UaM/xsbV4SOmV+uy9LvgsgRtFSqP7vOie7BOthzz2q1J4K0t8Xsb X-Received: by 10.98.7.140 with SMTP id 12mr29444802pfh.178.1525799141428; Tue, 08 May 2018 10:05:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525799141; cv=none; d=google.com; s=arc-20160816; b=okHH/AxK+ENbE75yp9LSk0V4nhV13K9B1r6xKr5E90R6JHNmt7c2O6tYAyzovnFFSf uhI2cZCkNDF1iC2/9qZs8nAgml5zxcepm1dmEr6bBmWRfl16qqhG7RXlQTZ9tGQzw4QM 7Nt4h+yBEDYojQd23/qiRvqMHbVGM658p1LZ2RrEhvG7feTIAcdcknUdsld/WR7ai0t7 nJLMRLR1ct5j0RukC5tMCO9xmezAxQUvuSdnGd1mV3FFv+HCbIQXDJwqaiuGYYo/yNau OKVRu0yJTFRHoQwim7zbPsklsM2VbF5UDTs3VG4ObSsCZGbZO71AOG07YKD3pZXv0w71 VpvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=uQlPF/bVLeYFIJ60gKiPRnssZkxM16jmyU+/Rvy5pEU=; b=bSrE2T/A47Ug2QKnb39ttnUKJJoDdXNX9pLdCKOMA8GxvPP9gUaidVQAXy0bDXvNcz tEawehYaUL31JePCgxcS+sd8dnK9jzpUha6iamhzEuNzkfoUUKH+rrYn0DmxCUqy+PIy 9YW488p+6hkM3hfG9Bzwz4x46nEVCJe354AOYK9hevRY7YB7co2j1OchmTZjnL3ub8i/ p4TJBd42HaPTTw4pMMlZ8IOEfnLvexhj+Oe8mzWES3sAzBgExNMNpE0W5FC1uOMytb2i 3aWTFVaLed3Wq6a7wgIQDj9rMYwURbpXTb3FCOP3ppoFGySnGFKJDxq5ebMMQ6/vL9/m PTcg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r9-v6si24650898plo.442.2018.05.08.10.05.26; Tue, 08 May 2018 10:05:41 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933223AbeEHQ6E (ORCPT + 99 others); Tue, 8 May 2018 12:58:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39984 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932368AbeEHQ6B (ORCPT ); Tue, 8 May 2018 12:58:01 -0400 Received: from smtp.corp.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 79C353002389; Tue, 8 May 2018 16:58:01 +0000 (UTC) Received: from w520.home (ovpn-116-103.phx2.redhat.com [10.3.116.103]) by smtp.corp.redhat.com (Postfix) with ESMTP id 22EC530012CD; Tue, 8 May 2018 16:58:00 +0000 (UTC) Date: Tue, 8 May 2018 10:57:59 -0600 From: Alex Williamson To: Bjorn Helgaas Cc: Logan Gunthorpe , 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, Stephen Bates , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , Bjorn Helgaas , Jason Gunthorpe , Max Gurtovoy , Dan Williams , =?UTF-8?B?SsOpcsO0bWU=?= Glisse , Benjamin Herrenschmidt , Christian =?UTF-8?B?S8O2bmln?= Subject: Re: [PATCH v4 00/14] Copy Offload in NVMe Fabrics with P2P PCI Memory Message-ID: <20180508105759.7dbaa8fe@w520.home> In-Reply-To: <20180507232346.GI161390@bhelgaas-glaptop.roam.corp.google.com> References: <20180423233046.21476-1-logang@deltatee.com> <20180507232346.GI161390@bhelgaas-glaptop.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Tue, 08 May 2018 16:58:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 7 May 2018 18:23:46 -0500 Bjorn Helgaas wrote: > On Mon, Apr 23, 2018 at 05:30:32PM -0600, Logan Gunthorpe wrote: > > Hi Everyone, > > > > Here's v4 of our series to introduce P2P based copy offload to NVMe > > fabrics. This version has been rebased onto v4.17-rc2. A git repo > > is here: > > > > https://github.com/sbates130272/linux-p2pmem pci-p2p-v4 > > ... > > > Logan Gunthorpe (14): > > 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 > > docs-rst: Add a new directory for PCI documentation > > PCI/P2PDMA: Add P2P DMA driver writer's documentation > > block: Introduce PCI P2P flags for request and request queue > > IB/core: Ensure we map P2P memory correctly in > > 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: Introduce helper functions to allocate and free request SGLs > > nvmet-rdma: Use new SGL alloc/free helper for requests > > nvmet: Optionally use PCI P2P memory > > > > Documentation/ABI/testing/sysfs-bus-pci | 25 + > > Documentation/PCI/index.rst | 14 + > > Documentation/driver-api/index.rst | 2 +- > > Documentation/driver-api/pci/index.rst | 20 + > > Documentation/driver-api/pci/p2pdma.rst | 166 ++++++ > > Documentation/driver-api/{ => pci}/pci.rst | 0 > > Documentation/index.rst | 3 +- > > block/blk-core.c | 3 + > > drivers/infiniband/core/rw.c | 13 +- > > drivers/nvme/host/core.c | 4 + > > drivers/nvme/host/nvme.h | 8 + > > drivers/nvme/host/pci.c | 118 +++-- > > drivers/nvme/target/configfs.c | 67 +++ > > drivers/nvme/target/core.c | 143 ++++- > > drivers/nvme/target/io-cmd.c | 3 + > > drivers/nvme/target/nvmet.h | 15 + > > drivers/nvme/target/rdma.c | 22 +- > > drivers/pci/Kconfig | 26 + > > drivers/pci/Makefile | 1 + > > drivers/pci/p2pdma.c | 814 +++++++++++++++++++++++++++++ > > drivers/pci/pci.c | 6 + > > include/linux/blk_types.h | 18 +- > > include/linux/blkdev.h | 3 + > > include/linux/memremap.h | 19 + > > include/linux/pci-p2pdma.h | 118 +++++ > > include/linux/pci.h | 4 + > > 26 files changed, 1579 insertions(+), 56 deletions(-) > > create mode 100644 Documentation/PCI/index.rst > > create mode 100644 Documentation/driver-api/pci/index.rst > > create mode 100644 Documentation/driver-api/pci/p2pdma.rst > > rename Documentation/driver-api/{ => pci}/pci.rst (100%) > > create mode 100644 drivers/pci/p2pdma.c > > create mode 100644 include/linux/pci-p2pdma.h > > How do you envison merging this? There's a big chunk in drivers/pci, but > really no opportunity for conflicts there, and there's significant stuff in > block and nvme that I don't really want to merge. > > If Alex is OK with the ACS situation, I can ack the PCI parts and you could > merge it elsewhere? AIUI from previously questioning this, the change is hidden behind a build-time config option and only custom kernels or distros optimized for this sort of support would enable that build option. I'm more than a little dubious though that we're not going to have a wave of distros enabling this only to get user complaints that they can no longer make effective use of their devices for assignment due to the resulting span of the IOMMU groups, nor is there any sort of compromise, configure the kernel for p2p or device assignment, not both. Is this really such a unique feature that distro users aren't going to be asking for both features? Thanks, Alex