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 3EF8DC3DA42 for ; Wed, 10 Jul 2024 06:27:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C2C566B0083; Wed, 10 Jul 2024 02:27:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB4906B0089; Wed, 10 Jul 2024 02:27:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A2CE66B008A; Wed, 10 Jul 2024 02:27:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8503C6B0083 for ; Wed, 10 Jul 2024 02:27:11 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 32ACF1C3A76 for ; Wed, 10 Jul 2024 06:27:11 +0000 (UTC) X-FDA: 82322860662.30.46EDF9D Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf13.hostedemail.com (Postfix) with ESMTP id 742A32001D for ; Wed, 10 Jul 2024 06:27:09 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720592813; 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; bh=OQu9eN1e2F2Cfdkhv8ZV9riRn7gffplRUvSc+bjovss=; b=c3Z9lhvOFCmvkxhvAnK4p7sGnU3eKQzcZ7y3g3siu1mxIrB9O15sRAL94CjZbsxAnwv6OT yv5/vmS1ORmBidaK0IvaXOjRlnAnDokFIObOfWgeOURuJXsuJ09vnXeK0WYoBN7cZChIYA 54LpxT/hRwrt/Cr3GLuUJ43VfcNLfg8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720592813; a=rsa-sha256; cv=none; b=USf0KKKvMl2FMkpwmwviRoF3FFQBtU3VnyTYQ5VWNDXTjOSm2Y2v7tROiIcjWxw83vv2C+ sg2nnZtsTlYLug/5H+rhAdwSNk1LcA8Pfs01DeAv8vhzI/N8UuF0D6hgD2RZ69S+C2pDpf l4dS7LXBl7v3TYOy5UiFNIPcLMJ4cUg= Received: by verein.lst.de (Postfix, from userid 2407) id 5C935227A87; Wed, 10 Jul 2024 08:27:04 +0200 (CEST) Date: Wed, 10 Jul 2024 08:27:04 +0200 From: Christoph Hellwig To: Jason Gunthorpe Cc: Christoph Hellwig , Leon Romanovsky , Jens Axboe , Robin Murphy , Joerg Roedel , Will Deacon , Keith Busch , "Zeng, Oak" , Chaitanya Kulkarni , Sagi Grimberg , Bjorn Helgaas , Logan Gunthorpe , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , Marek Szyprowski , =?iso-8859-1?B?Suly9G1l?= Glisse , Andrew Morton , linux-block@vger.kernel.org, linux-kernel@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 Subject: Re: [RFC PATCH v1 00/18] Provide a new two step DMA API mapping API Message-ID: <20240710062704.GA25953@lst.de> References: <20240703054238.GA25366@lst.de> <20240703105253.GA95824@unreal> <20240703143530.GA30857@lst.de> <20240703155114.GB95824@unreal> <20240704074855.GA26913@lst.de> <20240708165238.GE14050@ziepe.ca> <20240709061721.GA16180@lst.de> <20240709185315.GM14050@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240709185315.GM14050@ziepe.ca> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 742A32001D X-Stat-Signature: bc1zxq7xydgeisyh6tnoyuxpyuyqkrqc X-Rspam-User: X-HE-Tag: 1720592829-666556 X-HE-Meta: U2FsdGVkX18QOd/bzNif9CF13EgPvhOpZERNsz7Potdwllb71pkPUwdv4j7HkFYVh5Km3+X4cOlAKJ6WMZzUDW12V39Lx+y2BOq/ArYvCHUNNPtjQT8NCLNED5uwIAj72AJGWBtEWDkuEy1Q4usili6utPzfiuppq6KIp1LDf5UXB99uaxSiT+kugvRhCKTOVUIJA0m1/GhPTL/0tH05ueEwRBJBl5J8IDgWfdti2ZClaUkRD5Cu38SZ+cCPgfO1dj66S4KrtJLpt2PWZ8pKcDxFki6HXvUhezt9Kb1MiQE4hCSV3ILFMmp8Omm9P3eAhEjuPv8XLwiZO+BX5LeDF6DyrFrJWhYE0siMuG8LawgbMTHup0toirplmn7F2oV0roz/KjBxfuld4XmimuL2Mf0dzE8KK2nQ4n4WGfe6tIaI6Jceyq48juYOLfZGlx3WIrPV6dijLNRlLu/BpSXvAIjpaLLFnRQPs/fpMIKulxTf31dvJSRtAPd03hLfy5hJLcjj+uyNG/j4KkgmdtVbKE40W6z/sAgTJrGIHiiGifUq37mbKoDN7O3AMRgBXbCcWDi3HdiK/4jdxM3tDlaP/SIzSiCV4t5Rp0YQEPYg1FTu97h8qtD8J8LT+g4iWPJ7SUBpcKJ6zAKq3fYyeQkfKvmBYGyh0mFiitJxByKC+ug+hQoGcg6rUxF9OU65SdF37UhykFxsj2W3S6z7vTBJXcb+x1r+dgUU8nmrMMJe5Q99h/KPP1U7pK/VtyXY74IuW48bxcJBDB09b22cwpKB74sSMTHoPPzh2B+nwCGGIBgxH6zTD4Ca0woUa9pnyqC8shfybTf2Bl3yvKM+4PDQSrYbMBimXKKoR7dRRaa4MBOLm2ToDggcWktPYUa6bxuER/CG/5jwJuzgc4ySoQMCBlpDTSdDBQqD8JYYyshkMfdP9oukX4x1oSd3nep96KPREu7lN45VN+JuR0RLXHR rPzq2TyR umh/T9drgIcQKIcsm5opfz7Ypg+HoA1E+WaYzSCuLgplb2vtdm7Iq9/Fls1vwKo2rY97py1w80LUwbg4= 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: On Tue, Jul 09, 2024 at 03:53:15PM -0300, Jason Gunthorpe wrote: > > That whole thing of course opens the question if we want a pure > > in-memory version of the dma_addr_t/len tuple. IMHO that is the best > > way to migrate and allows to share code easily. We can look into ways > > to avoiding that more for drivers that care, but most drivers are > > probably best serve with it to keep the code simple and make the > > conversion easier. > > My feeling has been that this RFC is the low level interface and we > can bring our own data structure on top. > > It would probably make sense to build a scatterlist v2 on top of this > that has an in-memory dma_addr_t/len list close to today Yes, the usage of the dma_vec would be in a higher layer. But I'd really like to see it from the beginning. > . Yes it costs > a memory allocation, or a larger initial allocation, but many places > may not really care. Block drivers have always allocated a SGL, for > instance. Except for those optimizing for snall transfer of a single segment (like nvme). > My main take away was that we should make the dma_ops interface > simpler and more general so we can have this choice instead of welding > a single datastructure through everything. Yes, I don't think the dma_vec should be the low-level interface. I think a low-level interface based on physical address is the right one. I'll see what I can do to move the single segment map interface to be physical address based instead of page based so that we can unify them.