Received: by 10.213.65.68 with SMTP id h4csp3757103imn; Tue, 3 Apr 2018 10:08:22 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/FnLZkCOsKaO9Ekv1rp6KNnO5EH/VD2Os8BakLWjUcFqhf9FWcoXv5N5U4+Ljx9cx8kgOv X-Received: by 2002:a17:902:322:: with SMTP id 31-v6mr15093229pld.122.1522775302846; Tue, 03 Apr 2018 10:08:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522775302; cv=none; d=google.com; s=arc-20160816; b=jXgq+STWiaR8rKe4o+gvFkNPGO5g8BVtbvODnmo1B4SqLk/Yjf6zl/VdDOJfaAsflY G83mxinDt5bl6m4mtCtbJEjOssw6NTDVRa+d0rph4MQRNevV9nqtkN3vSh3YqW+YlMLR plIaQvreM7nLqKPNMtn7txH/MLXnMnwQQYCotjrxLCHbhgfXRxsdDocwU7GhakYHsyti P2qwJdud7gDJZrboO7zW3eIlJ1QptrT2Pvu3JNIhwUUKYBqIs0LawnhrrYGp+cyGfoQ4 nOGI429o6DeGdVddXKyuUA6la1ovZqN3gH9K2fxJ3GS5VMUgLbo7I1lhB62A3/P64wuU HI/w== 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:to:from:date :arc-authentication-results; bh=36sW7O3qKdzPaolaM2nsC71Mxse2z3UcYeqUEHOoCMM=; b=oySmGTX2KoIuoC2Aov0ekYlSef3eYkrcI9B2a15PrcgilkssZ1OiJ2ikmTn5M/+TXT 1rCBnvx4mpxp4aVUvzURHqosUI1rHEkHdhkDJBJgRHuO7hlEGtVf2z0PjtMSKEbAtsIL aFrWbeJr93JHfCEWICLzqMXtjcoQrF6lWBz9Y7D1979V0sOQl38aBV5ckMxHlwULU9y9 gzWnmmIlA3DWzl6zIPTxMv5H3wiCigKgzDSQifku8AuBaLAS6/v3h+BFYOqsCJk4nTqq GgnfDJGoLE5P3OXJS5VLYI37vobqgb9pPclXqRTE6U7Zg3oczkqBmjs8c1Nn7RTEsnat AClw== 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 y101-v6si937070plh.188.2018.04.03.10.08.08; Tue, 03 Apr 2018 10:08:22 -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 S1752488AbeDCRGt (ORCPT + 99 others); Tue, 3 Apr 2018 13:06:49 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:36334 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752397AbeDCRGs (ORCPT ); Tue, 3 Apr 2018 13:06:48 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 60CD44067EF0; Tue, 3 Apr 2018 17:06:47 +0000 (UTC) Received: from redhat.com (ovpn-121-77.rdu2.redhat.com [10.10.121.77]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0EB8CD7E18; Tue, 3 Apr 2018 17:06:47 +0000 (UTC) Date: Tue, 3 Apr 2018 13:06:45 -0400 From: Jerome Glisse To: christian.koenig@amd.com, linaro-mm-sig@lists.linaro.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/8] dma-buf: add peer2peer flag Message-ID: <20180403170645.GB5935@redhat.com> References: <20180325110000.2238-1-christian.koenig@amd.com> <20180325110000.2238-4-christian.koenig@amd.com> <20180329065753.GD3881@phenom.ffwll.local> <8b823458-8bdc-3217-572b-509a28aae742@gmail.com> <20180403090909.GN3881@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180403090909.GN3881@phenom.ffwll.local> User-Agent: Mutt/1.9.2 (2017-12-15) X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 03 Apr 2018 17:06:47 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 03 Apr 2018 17:06:47 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.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, Apr 03, 2018 at 11:09:09AM +0200, Daniel Vetter wrote: > On Thu, Mar 29, 2018 at 01:34:24PM +0200, Christian K?nig wrote: > > Am 29.03.2018 um 08:57 schrieb Daniel Vetter: > > > On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian K?nig wrote: > > > > Add a peer2peer flag noting that the importer can deal with device > > > > resources which are not backed by pages. > > > > > > > > Signed-off-by: Christian K?nig > > > Um strictly speaking they all should, but ttm never bothered to use the > > > real interfaces but just hacked around the provided sg list, grabbing the > > > underlying struct pages, then rebuilding&remapping the sg list again. > > > > Actually that isn't correct. TTM converts them to a dma address array > > because drivers need it like this (at least nouveau, radeon and amdgpu). > > > > I've fixed radeon and amdgpu to be able to deal without it and mailed with > > Ben about nouveau, but the outcome is they don't really know. > > > > TTM itself doesn't have any need for the pages on imported BOs (you can't > > mmap them anyway), the real underlying problem is that sg tables doesn't > > provide what drivers need. > > > > I think we could rather easily fix sg tables, but that is a totally separate > > task. > > Looking at patch 8, the sg table seems perfectly sufficient to convey the > right dma addresses to the importer. Ofcourse the exporter has to set up > the right kind of iommu mappings to make this work. > > > > The entire point of using sg lists was exactly to allow this use case of > > > peer2peer dma (or well in general have special exporters which managed > > > memory/IO ranges not backed by struct page). So essentially you're having > > > a "I'm totally not broken flag" here. > > > > No, independent of needed struct page pointers we need to note if the > > exporter can handle peer2peer stuff from the hardware side in general. > > > > So what I've did is just to set peer2peer allowed on the importer because of > > the driver needs and clear it in the exporter if the hardware can't handle > > that. > > The only thing the importer seems to do is call the > pci_peer_traffic_supported, which the exporter could call too. What am I > missing (since the sturct_page stuff sounds like it's fixed already by > you)? > -Daniel AFAIK Logan patchset require to register and initialize struct page for the device memory you want to map (export from exporter point of view). With GPU this isn't something we want, struct page is >~= 2^6 so for 4GB GPU = 2^6*2^32/2^12 = 2^26 = 64MB of RAM 8GB GPU = 2^6*2^33/2^12 = 2^27 = 128MB of RAM 16GB GPU = 2^6*2^34/2^12 = 2^28 = 256MB of RAM 32GB GPU = 2^6*2^34/2^12 = 2^29 = 512MB of RAM All this is mostly wasted as only a small sub-set (that can not be constraint to specific range) will ever be exported at any point in time. For GPU work load this is hardly justifiable, even for HMM i do not plan to register all those pages. Hence why i argue that dma_map_resource() like use by Christian is good enough for us. People that care about SG can fix that but i rather not have to depend on that and waste system memory. Cheers, J?r?me