From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5D4921B429 for ; Fri, 8 Nov 2024 15:38:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731080330; cv=none; b=IBocfr3YKJpQFhPFKQzoEFmQVw3Uw/BpIElQpG6MuZBpTlY/EPvv10pGZEw93JXHbkG+A7TNCLE2ivx2KWpapd392/GLHAWgqNwC7zuEfSJOboO/aeEg1hCUzlutJ2kAUg32xlaqvU/AQYrOYSvkNThu/KqjwX6t9QuI4XIpdT8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731080330; c=relaxed/simple; bh=OaBx3Fh/Km3ELqbio7v031NeuRfzJ9+4kTiWipNjW34=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PDT/TYddYnpiUsz+FE/ykWlkYRcra4SQAjUaPIQWVWsB6pCPWsszwxVTYADEKT5p4cdNx8WkXxClmPclNSiTHwod497QiISQiMSg5KRmOF49Zm4JoR9/+5Dle3LODNwA4cTHhTCmfc4iJ+3QgJzzRC3CWwR4C48bcZZp9ReaS0A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=aexEmqOU; arc=none smtp.client-ip=209.85.222.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="aexEmqOU" Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-7b1474b1377so148271485a.2 for ; Fri, 08 Nov 2024 07:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1731080328; x=1731685128; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7sMW5Kuv5sIzIjhBbBygI9fJdJpSk6eqM7+xgs0I9dY=; b=aexEmqOUtoWo0nIxpp53mWmhgcdamtlMoWnc7v23Dq2R4nF+XhtjhKeEQukniU5tde Vce5KIwE2ZP9zCpfoy/YAiCAgwmM+QhLn3FHxZhCVqcMcnaWCLkDNsKSdaR7TEYQYQny I7V8/zeoQnhPgNDMziuf1jeRFibRMTmxh1Jfgd73c+9VMrzfs8b59x9r8L0WM1bTzHZG X4YyruWQtaCHeiW6iXjx8oFUyTMzlhRe6kIpwqDXRLz/HFKrM3zjhj7yegME3+gB8JUw w3XqR9e5cqtLx9oPgONMCEZKywjVgwCbdxTX4YQWSbGgXCYWTAg8upYA74ViTR7IznHA v2dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731080328; x=1731685128; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7sMW5Kuv5sIzIjhBbBygI9fJdJpSk6eqM7+xgs0I9dY=; b=S3XWjvnKB0eIRYDPksFF42krg5Rk7pYE98ltglbk4yKj3MTpkjD15qASqID6FI2+La JvnVBpUHVb4Dhlg1FEo2/ti/n8q5rtJsGS8xoNoltJbNva6DKS0E9PSIiJba79i/e2gg VKbZHkerqavfUsIVz9ht0VK7NCPJmUHYFp9HDTHb9FLTpbDO/tlVCEPf33fISlCsG655 ZUP6QCjtZH/aE9LIzKzBF0pv0nPrceEMFhxOBdAYA7WL2ypLzpIV0xjZsQRcSWVl+NUr NpXyQ7GbijN49y7UIyqUMzaQvAxkQEQF4ZPvtopjyFOfZpdBqG54XbdPtjxteo7iXqF/ Vu4g== X-Forwarded-Encrypted: i=1; AJvYcCX+XMS+Aux18SiI1ab0StRu+bwuSup9agZLtMb5q+us+bJxSOMQm/vERWY9mocIysXWEKGUfAsnL2msbQU=@vger.kernel.org X-Gm-Message-State: AOJu0YxK5Uc7fA9x8icOmqrYLt2XD1GjxFaXnjS7Cz7SJ5y7ZczPdRla 821hg+kNRYzZ5tEv1nlBkGihaP5YGW7JEwS0ko8sHHHwtNzYDWHm93aDEyIP++Q= X-Google-Smtp-Source: AGHT+IHfTg/iLCK5GxrqZ9aoCzAZ7JH1FinF3HAR4KRwwnugOPp1CtA3KrYQyOs3W/lc98NgBjpBFQ== X-Received: by 2002:a05:620a:1a21:b0:7ac:bb00:cd42 with SMTP id af79cd13be357-7b331dd2d55mr406755285a.27.1731080327649; Fri, 08 Nov 2024 07:38:47 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-68-128-5.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.128.5]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b32ac2dd1fsm170869085a.15.2024.11.08.07.38.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Nov 2024 07:38:47 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1t9R4Q-00000002a9N-29Xq; Fri, 08 Nov 2024 11:38:46 -0400 Date: Fri, 8 Nov 2024 11:38:46 -0400 From: Jason Gunthorpe To: Christoph Hellwig Cc: Robin Murphy , Leon Romanovsky , Jens Axboe , Joerg Roedel , Will Deacon , Sagi Grimberg , Keith Busch , Bjorn Helgaas , Logan Gunthorpe , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , Marek Szyprowski , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Andrew Morton , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-rdma@vger.kernel.org, iommu@lists.linux.dev, linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, matthew.brost@intel.com, Thomas.Hellstrom@linux.intel.com, brian.welty@intel.com, himal.prasad.ghimiray@intel.com, krishnaiah.bommu@intel.com, niranjana.vishwanathapura@intel.com Subject: Re: [PATCH v1 00/17] Provide a new two step DMA mapping API Message-ID: <20241108153846.GO35848@ziepe.ca> References: <3567312e-5942-4037-93dc-587f25f0778c@arm.com> <20241104095831.GA28751@lst.de> <20241105195357.GI35848@ziepe.ca> <20241107083256.GA9071@lst.de> <20241107132808.GK35848@ziepe.ca> <20241107135025.GA14996@lst.de> <20241108150226.GM35848@ziepe.ca> <20241108150500.GA10102@lst.de> <20241108152537.GN35848@ziepe.ca> <20241108152956.GA12130@lst.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241108152956.GA12130@lst.de> On Fri, Nov 08, 2024 at 04:29:56PM +0100, Christoph Hellwig wrote: > On Fri, Nov 08, 2024 at 11:25:37AM -0400, Jason Gunthorpe wrote: > > I'm asking how it will work if you change the struct page argument to > > physical, because today dma_direct_map_page() has: > > > > if (is_pci_p2pdma_page(page)) > > return DMA_MAPPING_ERROR; > > > > Which is exactly the sorts of things I'm looking at when when I say to > > get rid of struct page. > > It will have to look up the page from the physical address obviously. > But at least only in the error path. I'm thinking we can largely avoid searching on physical, or at least we can optimize this so there is only one search on physical at the start of the DMA mapping. (since we are now saying all pages are the same type) > > What I'm thinking about is replacing code like the above with something like: > > > > if (p2p_provider) > > return DMA_MAPPING_ERROR; > > > > And the caller is the one that would have done is_pci_p2pdma_page() > > and either passes p2p_provider=NULL or page->pgmap->p2p_provider. > > And where do you get that one from? Which one? The caller must know the p2p properties of what it is doing because it is driving all the P2P logic around what APIs to call. Either because it is already working with struct page and gets it out of the pgmap. Or it is working with non-struct page memory and has a (MMIO address, p2p_provider) tuple that it got from the original driver that gave it the MMIO address. Or it really does have a naked phys_addr_t and it did the search on physical, but only once. Jason