From: "Christian König" <christian.koenig@amd.com> To: Logan Gunthorpe <logang@deltatee.com>, Christoph Hellwig <hch@infradead.org> Cc: linaro-mm-sig@lists.linaro.org, amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org Subject: Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev() Date: Thu, 29 Mar 2018 18:10:06 +0200 [thread overview] Message-ID: <8d050848-8970-b8c4-a657-429fefd31769@amd.com> (raw) In-Reply-To: <98ce6cfd-bcf3-811e-a0f1-757b60da467a@deltatee.com> Am 29.03.2018 um 17:45 schrieb Logan Gunthorpe: > > On 29/03/18 05:44 AM, Christian König wrote: >> Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe: >>> On 28/03/18 01:44 PM, Christian König wrote: >>>> Well, isn't that exactly what dma_map_resource() is good for? As far as >>>> I can see it makes sure IOMMU is aware of the access route and >>>> translates a CPU address into a PCI Bus address. >>>> I'm using that with the AMD IOMMU driver and at least there it works >>>> perfectly fine. >>> Yes, it would be nice, but no arch has implemented this yet. We are just >>> lucky in the x86 case because that arch is simple and doesn't need to do >>> anything for P2P (partially due to the Bus and CPU addresses being the >>> same). But in the general case, you can't rely on it. >> Well, that an arch hasn't implemented it doesn't mean that we don't have >> the right interface to do it. > Yes, but right now we don't have a performant way to check if we are > doing P2P or not in the dma_map_X() wrappers. Why not? I mean the dma_map_resource() function is for P2P while other dma_map_* functions are only for system memory. > And this is necessary to > check if the DMA ops in use support it or not. We can't have the > dma_map_X() functions do the wrong thing because they don't support it yet. Well that sounds like we should just return an error from dma_map_resources() when an architecture doesn't support P2P yet as Alex suggested. >> Devices integrated in the CPU usually only "claim" to be PCIe devices. >> In reality their memory request path go directly through the integrated >> north bridge. The reason for this is simple better throughput/latency. > These are just more reasons why our patchset restricts to devices behind > a switch. And more mess for someone to deal with if they need to relax > that restriction. You don't seem to understand the implications: The devices do have a common upstream bridge! In other words your code would currently claim that P2P is supported, but in practice it doesn't work. You need to include both drivers which participate in the P2P transaction to make sure that both supports this and give them opportunity to chicken out and in the case of AMD APUs even redirect the request to another location (e.g. participate in the DMA translation). DMA-buf fortunately seems to handle all this already, that's why we choose it as base for our implementation. Regards, Christian.
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org> To: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> Cc: linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev() Date: Thu, 29 Mar 2018 18:10:06 +0200 [thread overview] Message-ID: <8d050848-8970-b8c4-a657-429fefd31769@amd.com> (raw) In-Reply-To: <98ce6cfd-bcf3-811e-a0f1-757b60da467a-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org> Am 29.03.2018 um 17:45 schrieb Logan Gunthorpe: > > On 29/03/18 05:44 AM, Christian König wrote: >> Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe: >>> On 28/03/18 01:44 PM, Christian König wrote: >>>> Well, isn't that exactly what dma_map_resource() is good for? As far as >>>> I can see it makes sure IOMMU is aware of the access route and >>>> translates a CPU address into a PCI Bus address. >>>> I'm using that with the AMD IOMMU driver and at least there it works >>>> perfectly fine. >>> Yes, it would be nice, but no arch has implemented this yet. We are just >>> lucky in the x86 case because that arch is simple and doesn't need to do >>> anything for P2P (partially due to the Bus and CPU addresses being the >>> same). But in the general case, you can't rely on it. >> Well, that an arch hasn't implemented it doesn't mean that we don't have >> the right interface to do it. > Yes, but right now we don't have a performant way to check if we are > doing P2P or not in the dma_map_X() wrappers. Why not? I mean the dma_map_resource() function is for P2P while other dma_map_* functions are only for system memory. > And this is necessary to > check if the DMA ops in use support it or not. We can't have the > dma_map_X() functions do the wrong thing because they don't support it yet. Well that sounds like we should just return an error from dma_map_resources() when an architecture doesn't support P2P yet as Alex suggested. >> Devices integrated in the CPU usually only "claim" to be PCIe devices. >> In reality their memory request path go directly through the integrated >> north bridge. The reason for this is simple better throughput/latency. > These are just more reasons why our patchset restricts to devices behind > a switch. And more mess for someone to deal with if they need to relax > that restriction. You don't seem to understand the implications: The devices do have a common upstream bridge! In other words your code would currently claim that P2P is supported, but in practice it doesn't work. You need to include both drivers which participate in the P2P transaction to make sure that both supports this and give them opportunity to chicken out and in the case of AMD APUs even redirect the request to another location (e.g. participate in the DMA translation). DMA-buf fortunately seems to handle all this already, that's why we choose it as base for our implementation. Regards, Christian. _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2018-03-29 16:10 UTC|newest] Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-25 10:59 [PATCH 1/8] lib/scatterlist: add sg_set_dma_addr() helper Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 2/8] PCI: Add pci_find_common_upstream_dev() Christian König 2018-03-25 10:59 ` Christian König 2018-03-28 12:38 ` Christoph Hellwig 2018-03-28 15:07 ` Christian König 2018-03-28 15:07 ` Christian König 2018-03-28 15:47 ` Logan Gunthorpe 2018-03-28 16:02 ` Christian König 2018-03-28 16:02 ` Christian König 2018-03-28 16:25 ` Logan Gunthorpe 2018-03-28 18:28 ` Christian König 2018-03-28 18:28 ` Christian König 2018-03-28 18:57 ` Logan Gunthorpe 2018-03-28 19:44 ` Christian König 2018-03-28 19:44 ` Christian König 2018-03-28 19:53 ` Logan Gunthorpe 2018-03-29 11:44 ` Christian König 2018-03-29 15:45 ` Logan Gunthorpe 2018-03-29 16:10 ` Christian König [this message] 2018-03-29 16:10 ` Christian König 2018-03-29 16:25 ` Logan Gunthorpe 2018-03-29 18:15 ` Christian König 2018-03-29 18:15 ` Christian König 2018-03-30 1:58 ` Jerome Glisse 2018-03-30 1:58 ` Jerome Glisse 2018-03-30 6:33 ` Christoph Hellwig 2018-03-30 6:33 ` Christoph Hellwig 2018-03-30 15:25 ` Jerome Glisse 2018-03-30 18:46 ` Logan Gunthorpe 2018-03-30 19:45 ` Jerome Glisse 2018-03-30 19:45 ` Jerome Glisse 2018-04-02 17:02 ` Logan Gunthorpe 2018-04-02 17:20 ` Jerome Glisse 2018-04-02 17:20 ` Jerome Glisse 2018-04-02 17:37 ` Logan Gunthorpe 2018-04-02 19:16 ` Jerome Glisse 2018-04-02 19:16 ` Jerome Glisse 2018-04-02 19:32 ` Logan Gunthorpe 2018-04-02 19:45 ` Jerome Glisse 2018-04-02 19:45 ` Jerome Glisse [not found] ` <CADnq5_P-z=Noos_jaME9_CERri3C-m2hPPvx2bArr36O=1FnrA@mail.gmail.com> 2018-03-29 14:37 ` Alex Deucher 2018-03-29 14:37 ` Alex Deucher 2018-03-25 10:59 ` [PATCH 3/8] PCI: Add pci_peer_traffic_supported() Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 4/8] dma-buf: add peer2peer flag Christian König 2018-03-25 10:59 ` Christian König 2018-03-29 6:57 ` Daniel Vetter 2018-03-29 6:57 ` Daniel Vetter 2018-03-29 11:34 ` Christian König 2018-03-29 11:34 ` Christian König 2018-04-03 9:09 ` Daniel Vetter 2018-04-03 9:09 ` Daniel Vetter 2018-04-03 17:06 ` Jerome Glisse 2018-04-03 17:06 ` Jerome Glisse 2018-04-03 18:08 ` Daniel Vetter 2018-04-03 18:08 ` Daniel Vetter 2018-04-16 12:39 ` Christoph Hellwig 2018-04-16 12:39 ` Christoph Hellwig 2018-04-16 13:38 ` Daniel Vetter 2018-04-16 13:38 ` Daniel Vetter 2018-04-19 8:16 ` Christoph Hellwig 2018-04-19 8:16 ` Christoph Hellwig 2018-04-20 7:13 ` Daniel Vetter 2018-04-20 7:13 ` Daniel Vetter 2018-04-20 8:58 ` Christian König 2018-04-20 8:58 ` Christian König 2018-04-20 10:17 ` Christoph Hellwig 2018-04-20 10:17 ` Christoph Hellwig 2018-04-20 10:44 ` Christian König 2018-04-20 10:44 ` Christian König 2018-04-20 12:46 ` Christoph Hellwig 2018-04-20 15:21 ` [Linaro-mm-sig] " Daniel Vetter 2018-04-24 18:48 ` Christoph Hellwig 2018-04-24 18:48 ` Christoph Hellwig 2018-04-24 19:32 ` Daniel Vetter 2018-04-24 19:32 ` Daniel Vetter 2018-04-25 5:48 ` Christoph Hellwig 2018-04-25 5:48 ` Christoph Hellwig 2018-04-25 6:10 ` Alex Deucher 2018-04-25 6:10 ` Alex Deucher 2018-04-25 6:13 ` Daniel Vetter 2018-04-25 6:13 ` Daniel Vetter 2018-04-25 6:23 ` Daniel Vetter 2018-04-25 6:23 ` Daniel Vetter 2018-04-25 6:43 ` Christoph Hellwig 2018-04-25 6:43 ` Christoph Hellwig 2018-04-25 7:02 ` Daniel Vetter 2018-04-25 7:02 ` Daniel Vetter 2018-04-25 7:09 ` Christoph Hellwig 2018-04-25 7:09 ` Christoph Hellwig 2018-04-25 7:30 ` Daniel Vetter 2018-04-25 7:30 ` Daniel Vetter 2018-04-25 7:56 ` Thierry Reding 2018-04-25 7:56 ` Thierry Reding 2018-04-25 8:55 ` Christoph Hellwig 2018-04-25 8:55 ` Christoph Hellwig 2018-04-25 7:43 ` Thierry Reding 2018-04-25 7:43 ` Thierry Reding 2018-04-25 7:41 ` Thierry Reding 2018-04-25 7:41 ` Thierry Reding 2018-04-25 8:54 ` noveau vs arm dma ops Christoph Hellwig 2018-04-25 8:54 ` Christoph Hellwig 2018-04-25 8:54 ` Christoph Hellwig 2018-04-25 9:25 ` Russell King - ARM Linux 2018-04-25 9:25 ` Russell King - ARM Linux 2018-04-25 10:04 ` Daniel Vetter 2018-04-25 10:04 ` Daniel Vetter 2018-04-25 10:04 ` Daniel Vetter 2018-04-25 15:33 ` Christoph Hellwig 2018-04-25 15:33 ` Christoph Hellwig 2018-04-25 15:33 ` Christoph Hellwig 2018-04-25 21:35 ` Daniel Vetter 2018-04-25 21:35 ` Daniel Vetter 2018-04-25 21:35 ` Daniel Vetter 2018-04-25 23:26 ` Russell King - ARM Linux 2018-04-25 23:26 ` Russell King - ARM Linux 2018-04-26 9:17 ` Daniel Vetter 2018-04-26 9:17 ` Daniel Vetter 2018-04-26 9:17 ` Daniel Vetter 2018-04-26 9:09 ` Christoph Hellwig 2018-04-26 9:09 ` Christoph Hellwig 2018-04-26 9:09 ` Christoph Hellwig 2018-04-26 9:45 ` Daniel Vetter 2018-04-26 9:45 ` Daniel Vetter 2018-04-26 9:45 ` Daniel Vetter 2018-04-26 11:12 ` Russell King - ARM Linux 2018-04-26 11:12 ` Russell King - ARM Linux 2018-04-25 22:54 ` Russell King - ARM Linux 2018-04-25 22:54 ` Russell King - ARM Linux 2018-04-26 9:13 ` Christoph Hellwig 2018-04-26 9:13 ` Christoph Hellwig 2018-04-26 9:13 ` Christoph Hellwig 2018-04-26 9:20 ` [Linaro-mm-sig] " Daniel Vetter 2018-04-26 9:20 ` Daniel Vetter 2018-04-26 9:20 ` Daniel Vetter 2018-04-26 9:24 ` Christoph Hellwig 2018-04-26 9:24 ` Christoph Hellwig 2018-04-26 9:24 ` Christoph Hellwig 2018-04-26 9:39 ` Daniel Vetter 2018-04-26 9:39 ` Daniel Vetter 2018-04-26 9:39 ` Daniel Vetter 2018-04-25 6:24 ` [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag Alex Deucher 2018-04-25 6:24 ` Alex Deucher 2018-04-25 6:41 ` Christoph Hellwig 2018-04-25 6:41 ` Christoph Hellwig 2018-04-25 17:44 ` Alex Deucher 2018-04-25 17:44 ` Alex Deucher 2018-04-25 18:38 ` Dan Williams 2018-04-25 18:38 ` Dan Williams 2018-05-04 12:45 ` Lucas Stach 2018-03-25 10:59 ` [PATCH 5/8] drm/amdgpu: print DMA-buf status in debugfs Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 6/8] drm/amdgpu: note that we can handle peer2peer DMA-buf Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 7/8] drm/amdgpu: add amdgpu_gem_attach Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 11:00 ` [PATCH 8/8] drm/amdgpu: add support for exporting VRAM using DMA-buf Christian König 2018-03-25 11:00 ` Christian König 2018-03-28 12:37 ` [PATCH 1/8] lib/scatterlist: add sg_set_dma_addr() helper Christoph Hellwig 2018-03-28 12:37 ` Christoph Hellwig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8d050848-8970-b8c4-a657-429fefd31769@amd.com \ --to=christian.koenig@amd.com \ --cc=amd-gfx@lists.freedesktop.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=hch@infradead.org \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=logang@deltatee.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.