Received: by 10.192.165.148 with SMTP id m20csp4753733imm; Tue, 8 May 2018 13:51:47 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrbfRNTPUs3EiBR0t6Z1jzk52tHkNEf1elNFcJnRxY+EpPz8MfGIBfs//eFz3EJHHy9ZocY X-Received: by 10.98.127.145 with SMTP id a139mr41490469pfd.25.1525812707760; Tue, 08 May 2018 13:51:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525812707; cv=none; d=google.com; s=arc-20160816; b=ZjJrnZH/OtX4ZJIYC2iQgQiQXXU0oaSyP6ijPYrBo5loTyesnYMkFnev0o3WUUc4as hXOLxqiF2qvgk6Wy3G5STm2RGMw26Be12Xo8jPNhgDRrcOmXQjuTF1KaD4lFqOHu6ArB ayXvrDt3RQkoG5lrTcuOlp7S0LrjVl+0UvfHPfnuiIla9YZ7FUMI1kM63I6gyRswH/AS OE0jeXHaK2OiRNJOvXkCDh76Xfn/Qu7Hj5RDwLZ8tQP+R2FvuAM5iRswQYc4g+UWId3h B0daGooBG5Rg0Y1AipgerkBxe06qrrVKDjZwpXDL1yJyNLtnprkKXrzZaWxeFJGvLlqL qdag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=Mjp7yxk4RY0u7CyzJfeG/DDH8WdcdxcFI/kElb6EMoU=; b=gCoRrv8sizCfEHVY1rIz7d/cAvYKG+kU2zpS1ZoRW5l0Rwb/izmhSok88rqZ55Qbct VukVYbgFFynhHZmdjdhpMOqDjDSBsVc52eagNsTGzL6yWJM8TeRwv3ApkxiADcXKRWhr D1pj0JfKy0pCVSUM1V8QY2R7XgWcnk+QLzpUmy4Bs77LF7TvZWpKpPSwOmvEQ/Zk1s1R UZ8CqcReAG3nsMgP4UW5pPvHQR3F7miLHz1Nh3I/tjuO/G40zBROWsy9WcA/or+CVTqh 6H3DhSKc/3uZcR65g+nnVS3Voi3h01VkT66+Mjf5xfAu3okCuApLp4G2lzQYwlSKqNQ5 eCNw== 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 x24si5729566pfk.311.2018.05.08.13.51.32; Tue, 08 May 2018 13:51:47 -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 S932531AbeEHUuP (ORCPT + 99 others); Tue, 8 May 2018 16:50:15 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:44030 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932283AbeEHUuN (ORCPT ); Tue, 8 May 2018 16:50:13 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0805E8DC4A; Tue, 8 May 2018 20:50:12 +0000 (UTC) Received: from redhat.com (ovpn-120-65.rdu2.redhat.com [10.10.120.65]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A60172141200; Tue, 8 May 2018 20:50:07 +0000 (UTC) Date: Tue, 8 May 2018 16:50:06 -0400 From: Jerome Glisse To: Logan Gunthorpe Cc: Alex Williamson , Christian =?iso-8859-1?Q?K=F6nig?= , Bjorn Helgaas , 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 , Benjamin Herrenschmidt Subject: Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches Message-ID: <20180508205005.GC15608@redhat.com> References: <20180423233046.21476-5-logang@deltatee.com> <20180507231306.GG161390@bhelgaas-glaptop.roam.corp.google.com> <0b4183ef-e720-204b-9e85-b9eaf7a4136a@deltatee.com> <3584a6ac-95c7-5d23-1859-aee30605776e@deltatee.com> <20180508133407.57a46902@w520.home> <5fc9b1c1-9208-06cc-0ec5-1f54c2520494@deltatee.com> <20180508141331.7cd737cb@w520.home> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Tue, 08 May 2018 20:50:12 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Tue, 08 May 2018 20:50:12 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'jglisse@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 08, 2018 at 02:19:05PM -0600, Logan Gunthorpe wrote: > > > On 08/05/18 02:13 PM, Alex Williamson wrote: > > Well, I'm a bit confused, this patch series is specifically disabling > > ACS on switches, but per the spec downstream switch ports implementing > > ACS MUST implement direct translated P2P. So it seems the only > > potential gap here is the endpoint, which must support ATS or else > > there's nothing for direct translated P2P to do. The switch port plays > > no part in the actual translation of the request, ATS on the endpoint > > has already cached the translation and is now attempting to use it. > > For the switch port, this only becomes a routing decision, the request > > is already translated, therefore ACS RR and EC can be ignored to > > perform "normal" (direct) routing, as if ACS were not present. It would > > be a shame to go to all the trouble of creating this no-ACS mode to find > > out the target hardware supports ATS and should have simply used it, or > > we should have disabled the IOMMU altogether, which leaves ACS disabled. > > Ah, ok, I didn't think it was the endpoint that had to implement ATS. > But in that case, for our application, we need NVMe cards and RDMA NICs > to all have ATS support and I expect that is just as unlikely. At least > none of the endpoints on my system support it. Maybe only certain GPUs > have this support. I think there is confusion here, Alex properly explained the scheme PCIE-device do a ATS request to the IOMMU which returns a valid translation for a virtual address. Device can then use that address directly without going through IOMMU for translation. ATS is implemented by the IOMMU not by the device (well device implement the client side of it). Also ATS is meaningless without something like PASID as far as i know. Cheers, J?r?me