Received: by 10.213.65.68 with SMTP id h4csp1195529imn; Wed, 14 Mar 2018 12:30:23 -0700 (PDT) X-Google-Smtp-Source: AG47ELuBEVtFkjpEz/IAt97iZQqHUxqPaRNrGS1Qeqxw7hLyPoe37mvlZq9J3xpG7aNefCcraai1 X-Received: by 10.101.101.78 with SMTP id a14mr4546826pgw.368.1521055823219; Wed, 14 Mar 2018 12:30:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521055823; cv=none; d=google.com; s=arc-20160816; b=a20I+8va6iXywiC0CNOJMAzVJ2BnO6KTa0sA80PYzXygYr/mUc1L/LGI2lprlxonNL lPiwmsjfiADgAq8m6eEXX1JJAt4mi0SYLE9C0TChXeF5I0EejpnoZl6kafN3EEjYS6Sh JuyGxoE6ZqERSIudiayCACR6gtcCiaA1WUDqq9QJaWgFVRKYIrsG+IVq1p5hVGaf8KOi cw7zt6uHAlaWOQWiU7Tm4gdES4Vc1tPbgGNE22szQKXWBFA19wz+PepI940FSmaoPBIe bEQxYkXLIX2Iz+JKpfiGM24tqCJQljkYGADu1UohIsxAlvSSId2kjAHR3rlF2JMdJURu 4PAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=xUBAzWIRSEQC1+bAHlxoUY2k/DacE30M3TbM0qKEsWU=; b=XudBJUNi/EsX3wsZDh7gHcclO/wPFVc95rwbpCKiAvfOLERA/CejvF3BlgZEeWV7lD GpFjnu9/Nw9e2TgCFc4b7y2csn1BMbRyZ8YrfgRnllW0LWubXRlKU3P1po6iHwK59za0 3fyOzwwaB6kXRv/QMpACXZpL5vWLe3NpKsF8chzIL3zbajVvSaXA8eSE1AtsP4MNB475 0Wt9OrTRnN9nxV5agc6Ms6Agm4z6lcNTVxM58/gZx8dgwdOly6K/aiRIyf0xc1xr903X UMKSClt9E17ut6VKr950OPpWI+YhC7wdDxkbIX6AQ3Xg6JySiVZXEtZ/aWTOZvAj7asM yIQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=YabnR90q; 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 n12si2553236pfj.207.2018.03.14.12.30.06; Wed, 14 Mar 2018 12:30:23 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=YabnR90q; 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 S1751991AbeCNT2U (ORCPT + 99 others); Wed, 14 Mar 2018 15:28:20 -0400 Received: from mail-oi0-f51.google.com ([209.85.218.51]:39808 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751781AbeCNT2F (ORCPT ); Wed, 14 Mar 2018 15:28:05 -0400 Received: by mail-oi0-f51.google.com with SMTP id u190so2939306oif.6 for ; Wed, 14 Mar 2018 12:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xUBAzWIRSEQC1+bAHlxoUY2k/DacE30M3TbM0qKEsWU=; b=YabnR90q4AvBfwqRrQlLVuXiHwirWG1l4PW21dDqWRsWN1q61fM/QnVkJznV9k0cHa zKzne1jaZVBCZmSbHW8JjvjOfO3gLjysVrGpWyaIynDvHMwAV3/t/0KIhu9FvWC8o5Fs IgFEWP388eeR/FHDEX+gJKIpG5l1pCjgvNolDNGdFlubE+pXO+3zcPC2SYlcAAaEaAN4 EbRB9qZc9Ya9RmsKkXRGGIz38LTmvZz81JizTNUcEUc47izOU5tq9axVuW2O8wwtxFG6 gaO3RfO8Ui1iphlB2cv8SKEYpMq1bqoRShPmxvfX67Q8h+AaKxvR7a2FR/wJ9sIkSOTA rHzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xUBAzWIRSEQC1+bAHlxoUY2k/DacE30M3TbM0qKEsWU=; b=U4gEJT9pc+v3JjtGBmQuoPFzrIsAGpTt7x1ucm6DOE/XamXfAul0o6XAkRRClnfWSN +rUU3he4GYdt8qKjRDLHtlOhjuwp6eIXz5gGLWbSjXyWwocJfUpZjepU1ZUSj4l5LTM6 GfySK44j16Krtyjg62fwUg8kE8XFzycW4cgEWj+j9WMoH7lv2S6DMZ9nM3CnVoE8QquZ D7j1bJ8hzGazPdiKX/Il4FYvMakBrRjWweswfbSP4ydXQLq7X5oqNlnMAOGrjjLoIL+l YCGx304I/prrYgpbX9kfhVHinxyD/YUrujQQO/SCaK/06PXjwOy60BRaQZGOhbxHYyJk zJiA== X-Gm-Message-State: AElRT7Hq40VQiqhfvwXu/5AijA6Q0kd5tLCKZEI4E/bFcozz32vFy0U5 Na/PVVaQnoJmECyxlj97ZCkVRxyZ1fA5ljzJ244HxQ== X-Received: by 10.84.68.7 with SMTP id k7mr3354975oiw.118.1521055684781; Wed, 14 Mar 2018 12:28:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:5189:0:0:0:0:0 with HTTP; Wed, 14 Mar 2018 12:28:04 -0700 (PDT) In-Reply-To: References: <3ea80992-a0fc-08f2-d93d-ae0ec4e3f4ce@codeaurora.org> <4eb6850c-df1b-fd44-3ee0-d43a50270b53@deltatee.com> <757fca36-dee4-e070-669e-f2788bd78e41@codeaurora.org> <4f761f55-4e9a-dccb-d12f-c59d2cd689db@deltatee.com> <20180313230850.GA45763@bhelgaas-glaptop.roam.corp.google.com> <8de5d3dd-a78f-02d5-0eea-4365364143b6@deltatee.com> <20180314025639.GA50067@bhelgaas-glaptop.roam.corp.google.com> <112493af-ccd0-455b-6600-b50764f7ab7e@deltatee.com> <20180314185159.GD179719@bhelgaas-glaptop.roam.corp.google.com> From: Dan Williams Date: Wed, 14 Mar 2018 12:28:04 -0700 Message-ID: Subject: Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory To: Logan Gunthorpe Cc: Bjorn Helgaas , Stephen Bates , Sinan Kaya , "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" , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , Bjorn Helgaas , Jason Gunthorpe , Max Gurtovoy , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Benjamin Herrenschmidt , Alex Williamson Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 14, 2018 at 12:03 PM, Logan Gunthorpe wrote: > > > On 14/03/18 12:51 PM, Bjorn Helgaas wrote: >> You are focused on PCIe systems, and in those systems, most topologies >> do have an upstream switch, which means two upstream bridges. I'm >> trying to remove that assumption because I don't think there's a >> requirement for it in the spec. Enforcing this assumption complicates >> the code and makes it harder to understand because the reader says >> "huh, I know peer-to-peer DMA should work inside any PCI hierarchy*, >> so why do we need these two bridges?" > > Yes, as I've said, we focused on being behind a single PCIe Switch > because it's easier and vaguely safer (we *know* switches will work but > other types of topology we have to assume will work based on the spec). > Also, I have my doubts that anyone will ever have a use for this with > non-PCIe devices. P2P over PCI/PCI-X is quite common in devices like raid controllers. It would be useful if those configurations were not left behind so that Linux could feasibly deploy offload code to a controller in the PCI domain.