From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43856C7115B for ; Mon, 23 Jun 2025 13:46:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB6E96B00BF; Mon, 23 Jun 2025 09:46:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D8E516B00C0; Mon, 23 Jun 2025 09:46:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA4CA6B00C1; Mon, 23 Jun 2025 09:46:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B67666B00BF for ; Mon, 23 Jun 2025 09:46:58 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D38F0C04FC for ; Mon, 23 Jun 2025 13:46:57 +0000 (UTC) X-FDA: 83586791274.27.E7503E7 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf16.hostedemail.com (Postfix) with ESMTP id 929C6180007 for ; Mon, 23 Jun 2025 13:46:54 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=HxtUApuq; spf=none (imf16.hostedemail.com: domain of BATV+617475e3227a0a436e26+7974+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+617475e3227a0a436e26+7974+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750686416; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ana0bJ8hg2451El2QUEf36H2FD1ZACNayjwsD6jvG/A=; b=MILSkXxXyocwg1oU0k8ad8zYnpGFYpgpd/6FK6XpiMUzn9scfZboCUL1bl6rGFyljg0mg1 tZBK+wuvZOr8rPWdD5z5RHx10cw8VBKGWGqLy9Pc1SoTwWzVHvBLC3phVzycITzhbWSCg1 snvO5ny/TEdmqODd8ZNLmZDBI21NE4Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750686416; a=rsa-sha256; cv=none; b=X1jcfAJ/ZoOwbVBmBq4m49z0vqo0z1L17zOmeAzjHcJDZk2gsvsAsTXtCkIf/8kLuIAOLB oTp+VdH3bxWvi79GK6+UmgSu6Hpy8kwALqW7dcQlzJkdJ2hM+34DXxTRx0Tp5C96LLpyGE j4usgtKag752wSojuj+/aI+R4Vr2BbI= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=HxtUApuq; spf=none (imf16.hostedemail.com: domain of BATV+617475e3227a0a436e26+7974+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+617475e3227a0a436e26+7974+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ana0bJ8hg2451El2QUEf36H2FD1ZACNayjwsD6jvG/A=; b=HxtUApuqIxjQJ05HeYehUPlPmt HblO84+kpcn33Jvf5y85M4E7ksoqHdRegguU2ClgTmVAzHOp9nOcma5AIOH1jXggvasOHWwly4zzn 60U7UYcz5apZggiJD5DyWdIETDnYoLq72uWAtgvLV7M8xnDkuhC2wKMs7uDamgf0SLdKhxPMsIqaD pfejZy+sEDFFcEG8gP5OczwtZgk3RxHSAOZPDoeSOjy4+Fux1KdPIiVc1kz7aQSF/93akpKO2dk1P ya4PbjJtM2pjpxDbzIlnELNWbjbhZnjC0QxRI6L0qJbx/pOHweI9dQE647dQ2vbHjbqkBZEYbMkbX GfruIkCA==; Received: from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uThVX-00000002uw7-2IPu; Mon, 23 Jun 2025 13:46:47 +0000 Date: Mon, 23 Jun 2025 06:46:47 -0700 From: Christoph Hellwig To: David Howells Cc: Christoph Hellwig , Andrew Lunn , Eric Dumazet , "David S. Miller" , Jakub Kicinski , David Hildenbrand , John Hubbard , Mina Almasry , willy@infradead.org, Christian Brauner , Al Viro , netdev@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Leon Romanovsky , Logan Gunthorpe , Jason Gunthorpe Subject: Re: How to handle P2P DMA with only {physaddr,len} in bio_vec? Message-ID: References: <2135907.1747061490@warthog.procyon.org.uk> <1069540.1746202908@warthog.procyon.org.uk> <165f5d5b-34f2-40de-b0ec-8c1ca36babe8@lunn.ch> <0aa1b4a2-47b2-40a4-ae14-ce2dd457a1f7@lunn.ch> <1015189.1746187621@warthog.procyon.org.uk> <1021352.1746193306@warthog.procyon.org.uk> <1098395.1750675858@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1098395.1750675858@warthog.procyon.org.uk> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 929C6180007 X-Stat-Signature: maupg15kwxhccofrrfrrksn5b1gcidyq X-Rspam-User: X-HE-Tag: 1750686414-744402 X-HE-Meta: U2FsdGVkX1+1mx2WGXerhfF4FloUx62mcko6iekVYUSVWBLsWp45UnWPUlA+Vume/re6tVapbFuiUHBUJEBZL2K6ntGOx4Ye24NvNivd/TxYDeG2Snzh1a8ymHkZS3iXgYqlSzebAtvYEetl0Cbznc86Pe+Q+/+1vso58eOeQjGXBs6/8z2DRM56cL2zULbfVoxi5xn6mrVro0zvo5gU7EvI1kmCGvBFoBRQuytFr63aWcNDstcqo+Jc7EfCjvZAZYJvd4Pc6hYxr23iDZFLCMMQoYSeW94GzzFZfLTXKDOtxGJgC56O62T72T1E5947tiWLyfarU4s2FI6WMQ7InHnkxaQX5GEteZYGgXxsb0kC8LE/mfsvieFvw+IaGo4GgYAmg26JI+QU2UWgP8PTXE8kwrdBaTbGrsWlJ2pT9Bl7X4lyZNIls3SKP54L4LFZeH9IAqFVu2CaFVhZv3cfMuPXbvClsNFYUz+kJZJqNsKA6z1li1ekDzVF+k7vqCTuezaFN6Fg+eCO4bL2MY815Krq99opAZ52MwKksS6XJT2+vA9klv5G13MBdmYW5IMq1KuW69FSogWqKTQqhuP1mqeKiE65FguryugKHUWeLyru1FEE4eo5WZD8SBJltECChXbWh91ncZ8E2M1l93RTNxMAQXodm5pxu8BqkksBHibBbUIyc+6yHkvT+LRVPj6GjPPMQ/W9Tlufrh4YycTpqu/jaNouKr4v0fiunJ6ms1Xvw3SlC0biIraj3byiAo7s+GSuFywaVh7fXJae7OVwuRt5gc11b/sbsd+4QkXGl6iWwrq/n6aFDcLVfAIFDyyCsHCcFeXlzYZTq6AnzBDgRtifteEiY6nFtyXEZANf5b0ullJ/CZC4zsHwlbYWgEPdW+yqlMqZ11uudUNSgPRKs+DWkllVs0yO5v+xZbpyZJWH+0GIvuD7I45OFBSTsmUsKIG3jI8oOQINWyq3G5B AAQyrrn/ Nw1AwdlvU/CbYFC/SYgZCNBvpAYguIeSf7IjreNmsT9V3eweHWuWLGzfLrUwMbgnjoPsn4LOWsJe2ENwBAbfNwkDdOxNLs/CFdkGvEXUCiNExPoPyWW5QIcTnHeCDC+3UvEYvilqUFWl80DZbfB8/d/XLXGUwTeOwLxY9Nt9iEJRMV5J9Q4n0pYayTJ+DxVqgUXQb4lnjkUJgCu0RM8mAZzUYM/PHWwZvt8e7xEOnE16CdmGCDTW2IWXYNlhGG6Uz0r9xRQlq/YvENMXr1i/KvdRksF4ReKsnWm3AOaSpYILPX3+InJTS/PU4sSY9jR/cOkCCx9bOLzKwgAzADYKrSJ6rKlrRq/4UClxNfad+CvFEiEnTPSuuQ2en3+04DPnpnFPooS/OCQEdxbcBpUC7xFl6ahkW8RaxyqOXYRbleE6FKHwc7Dw1+pujNTqoBwXjTBHRbBb/TaycqfcLP4tkGJAwoAnvoF0nWSYOEDOIPvQjlGDxBkXm07OW2B+OkjrTLf40jPIomZTT6HVSLdLCzcjI5WKZtqcMQG2+1ZUFzv/1nxejGj/OU9HEQc56o4EKfeEr X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi David, On Mon, Jun 23, 2025 at 11:50:58AM +0100, David Howells wrote: > What's the best way to manage this without having to go back to the page > struct for every DMA mapping we want to make? There isn't a very easy way. Also because if you actually need to do peer to peer transfers, you right now absolutely need the page to find the pgmap that has the information on how to perform the peer to peer transfer. > Do we need to have > iov_extract_user_pages() note this in the bio_vec? > > struct bio_vec { > physaddr_t bv_base_addr; /* 64-bits */ > size_t bv_len:56; /* Maybe just u32 */ > bool p2pdma:1; /* Region is involved in P2P */ > unsigned int spare:7; > }; Having a flag in the bio_vec might be a way to shortcut the P2P or not decision a bit. The downside is that without the flag, the bio_vec in the brave new page-less world would actually just be: struct bio_vec { phys_addr_t bv_phys; u32 bv_len; } __packed; i.e. adding any more information would actually increase the size from 12 bytes to 16 bytes for the usualy 64-bit phys_addr_t setups, and thus undo all the memory savings that this move would provide. Note that at least for the block layer the DMA mapping changes I'm about to send out again require each bio to be either non P2P or P2P to a specific device. It might be worth to also extend this higher level limitation to other users if feasible. > I'm guessing that only folio-type pages can be involved in this: > > static inline struct dev_pagemap *page_pgmap(const struct page *page) > { > VM_WARN_ON_ONCE_PAGE(!is_zone_device_page(page), page); > return page_folio(page)->pgmap; > } > > as only struct folio has a pointer to dev_pagemap? And I assume this is going > to get removed from struct page itself at some point soonish. I guess so.