From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966956AbeCAKcB (ORCPT ); Thu, 1 Mar 2018 05:32:01 -0500 Received: from mail-wr0-f196.google.com ([209.85.128.196]:33817 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935717AbeCAKb6 (ORCPT ); Thu, 1 Mar 2018 05:31:58 -0500 X-Google-Smtp-Source: AG47ELsA7VXWUB3BqAwRVSyMeXN6aq/YMQuYwkR8i6JK6ZzNTvP2E6G5GR84RJMY6GoWiNQ6WTOVxg== Subject: Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory To: 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 Cc: Stephen Bates , Christoph Hellwig , Jens Axboe , Keith Busch , Bjorn Helgaas , Jason Gunthorpe , Max Gurtovoy , Dan Williams , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Benjamin Herrenschmidt , Alex Williamson References: <20180228234006.21093-1-logang@deltatee.com> From: Sagi Grimberg Message-ID: <90b658d9-da8a-af36-ad8f-a72ef0c6e3c1@grimberg.me> Date: Thu, 1 Mar 2018 12:31:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180228234006.21093-1-logang@deltatee.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Hi Everyone, Hi Logan, > 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. That's good, but what would happen for these devices? simply fail the mapping causing the ulp to fail its rdma operation? I would think that we need a capability flag for devices that support it.