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 61763C3DA41 for ; Tue, 9 Jul 2024 06:17:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1C196B0099; Tue, 9 Jul 2024 02:17:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCC7D6B009A; Tue, 9 Jul 2024 02:17:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B94826B009B; Tue, 9 Jul 2024 02:17:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 98F806B0099 for ; Tue, 9 Jul 2024 02:17:29 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E973F1416DC for ; Tue, 9 Jul 2024 06:17:28 +0000 (UTC) X-FDA: 82319207376.24.9EB98DA Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf10.hostedemail.com (Postfix) with ESMTP id F0731C0017 for ; Tue, 9 Jul 2024 06:17:26 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.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=1720505832; 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=aCNTWVYaP51zgkYgTkFQITxMZCYoN3ocgkKQSV5XmJ4=; b=TRTT2s42Gtt8zJ1A+eMHEgBs0oLJ0GGJ06tlFzdE6VghZ3zpQdXcbU+v+AMdGcBim8/qzY DGA9m/yZjrkTirE3jGyeuMe91a4EEsqm0HuoOVJqPcM3RhpmfhvhqkqCE6EZhWMm98Tcwq QXDqxeYiJyR1Xmq38sXB93xVH8qRNII= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.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=1720505832; a=rsa-sha256; cv=none; b=DE9iQgamNvEnwaYiq1HHqfVLwws504GS0+j5i1NG+JQJtW+mgtbj2Oyp+YMaztHsGq0gTT 5e5cQRk8WB8vdX7mxcbs0brgoqq/Z+rphDaUPBF/vcRE2fcXZB5UuMA7NTAiuSTUSZa1hr kSKRR7qimyUkgPObXxbmWwmpruPi1HE= Received: by verein.lst.de (Postfix, from userid 2407) id 52C0568AFE; Tue, 9 Jul 2024 08:17:21 +0200 (CEST) Date: Tue, 9 Jul 2024 08:17:21 +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: <20240709061721.GA16180@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240708165238.GE14050@ziepe.ca> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: F0731C0017 X-Stat-Signature: 658kh956bkuugdfq54r7die99xpbk9mc X-HE-Tag: 1720505846-547014 X-HE-Meta: U2FsdGVkX1+o1AC9V877mIWrOuuPI27eIWfIbiYzmz5COGgDwZ1JvT9eABZufdCXoM9C6/wW2unPT5ZVTjw0a1O0ZxlNFNX1aWQKyZiOW+xsyS/Ih9s2YJyJoOUnRKPazhSchwiv5IlzHw538iKYZoITByn1WimOySEbR4Wbi3l0kNtMLjww9WCx5P79MySxn5LIlyhAC+ctWSA36gd5eA3MhV+v4f7bzMuiIinXJMF/ImscRTPUqj4bdwxxmYv6HP90FYoqaQZg1FyFNgvX0ya8SPKXt97lizCCs93CnqEnSioiy3pZZTdtyU0VSoKSblZFABc1gFaEzD2k3jhAjy8s0pscjqEy5rIoX34cZGidfqnYlk+tgWMhfsuaXRZpnaR06jy0fx28NWz2Mq42WnzsitkYtzWQtWIOmibKDGDLkPwSHAs9DYAbVMUgh+KMtZlpBzyJIXPkbfw4D/qTNOZwcqqkzCJjUFZQCvg3gXY9NbcDF0C9+resqmkeTQmdngRz6eSx+zCex+Dq0lWG6t5u3oxYZ2boeeDmRArYp8+c5j2o2EJj/WJETf3SRE0tvtB/EYGAIb+0PZwMe3mrbgD5G6eM+O7Vjp4+BHYnyfn96894iZh2Sqv0NDEAgqbFNueEKWY1MyYr2mf5cIWMcIfZXsiN9cYupZfk7gqggiu59+FBw4PcUZv5j2P3B5mwDWT90QHWgNOr/2YYveeS3v21mggZI2/dPYdyQYLygNBUJFdep12y1i+bxWe9bVA327tm5cZmuk+263SOsbYPsJFB+/s/cO7IQTcbdTOzRQC7ADGvOT6It7f30X+A97BakpzLCkoFPpXOhFQCAkEcDhSDXoH3agLtMrvfGYd5PKrAANP2Io9CFEP4LgthqXbvrV0wI8l7Ra0Iq1DC4Qh6Cww/wxKKmd5qqXwEwYQYJ3jL/G+VX+DVzo1q3hdfLD4W4JbIJVorrIv3NSsdqbp QUmrC9yL 6ala9NpW7kW9I8KdNlk5BEHQ6dsvz1F0MXd4/nnbRr3KuYGWKTLK42SczCPgClsXgvhust8OGlHfDP/0= 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 Mon, Jul 08, 2024 at 01:52:38PM -0300, Jason Gunthorpe wrote: > Ideally we'd have some template code that consolidates these loops to > common code with driver provided hooks - there are a few ways to get > that efficiently in C. > > I think it will be clearer when we get to RDMA and there we have the > same SGL/PRP kind of split up and we can see what is sharable. I really would not want to build common code for PRPs - this is a concept very specific to RDMA and NVMe. OTOH more common code SGLs would be nice. If you look at e.g. SCSI drivers most of them have a simpe loop of mapping the SG table and then copying the fields into the hardware SGL. This would be a very common case for a helper. 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. > I'm also cooking something that should let us build a way to iommu map > a bio_vec very efficiently, which should transform this into a single > indirect call into the iommu driver per bio_vec, and a single radix > walk/etc. I assume you mean array of bio_vecs here. That would indeed nice. We'd still potentially need a few calls for block drivers as requests can have multiple bios and thus bio_vec arrays, but it would still be a nice reduction of calls.