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 38A49C3065C for ; Thu, 4 Jul 2024 07:49:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C20086B00B4; Thu, 4 Jul 2024 03:49:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA8F26B00B6; Thu, 4 Jul 2024 03:49:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A22676B00B7; Thu, 4 Jul 2024 03:49:04 -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 813BB6B00B4 for ; Thu, 4 Jul 2024 03:49:04 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 06A9E410B8 for ; Thu, 4 Jul 2024 07:49:04 +0000 (UTC) X-FDA: 82301294208.05.4E3ED7A Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf24.hostedemail.com (Postfix) with ESMTP id 1D8A3180018 for ; Thu, 4 Jul 2024 07:49:01 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720079324; a=rsa-sha256; cv=none; b=5w6Ufb7iyfW451/gRIxdM+b1W64tr7F0wGLEK99k6hDkByrO8vO013Ae3FigmqM8ncdfUb tSN03jldth3DjskTwiFEFeSV184bPMT6Xu07csSuHJX++/B6FB0Wus4vPohYN5D8jFbWt7 jByLP1ks7ymayUjqEw75PBSsXa6FDO0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720079324; 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=TOWEFNPLCPH2NjVWmElBI7VnpkJseOiXr3UYCCHK9eY=; b=Ao/tq5Xc4lXitiKB0+0RCsl7wW9nOcPI/EPaHoVnXt2YT8Mw8pstHgzwOqTeSF1S8pPr76 Thj0uUaJoKyQ8+WA9m4DQmrRYT4s8f4QiavyPI1vd93aDqsTZD6BcatMkJAHc4x/cmwdHf 4GdIGU5h2Xe+vRwtxVRzopjQrMjMR5c= Received: by verein.lst.de (Postfix, from userid 2407) id 52B5468AA6; Thu, 4 Jul 2024 09:48:56 +0200 (CEST) Date: Thu, 4 Jul 2024 09:48:56 +0200 From: Christoph Hellwig To: Leon Romanovsky Cc: Christoph Hellwig , Jens Axboe , Jason Gunthorpe , 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: <20240704074855.GA26913@lst.de> References: <20240703054238.GA25366@lst.de> <20240703105253.GA95824@unreal> <20240703143530.GA30857@lst.de> <20240703155114.GB95824@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240703155114.GB95824@unreal> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Queue-Id: 1D8A3180018 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: x71s8fjtq3ksfdopdu1u4nrti4g93n9t X-HE-Tag: 1720079341-688234 X-HE-Meta: U2FsdGVkX1+ZliKEwYpThNfgccgOOmZTiXGGxu1LsXC5lztKIwpaLIMETwnc/KcUmvzMKJBxCY1SOcJtCBJSGkoT2dLjh0NPZOMavKmJOSUYw3xGNxnkx3nIPd3L7beU2qMVQL2v9mLNodHRwS+R1I16guStRDm/vdIgHcNJDKiMzIqQq0l0m2AfJQ3+8aqaD8bhJKCwRZ8JMIJxw/bckaotFWjGGdk7d9oZtFd/9RTn7IC9jdm7KAJvRnQ8y20UudfkwkAbYBSjtzFFqJJnsc1TDS2x5/YFihJS2hiHbgajAaME1IUwfoCXgR+KDcrnKE4rKvg8dZbX56LSjUJ9e0Mi2t7BOOZ3yxlmi2qIkONGo5Dg1DkB6SPgIkcmgkv6v+rj49PsNJPPppnoXxP3tBVd48+DcoesL/iypzHglVGi/cD70337Fsqofx2D/2XkHDBZ3G/LOdGDqiXbh1jclJmNHJg4BReSX1Qk+rSdYMr81trkbfU15pv2nxxiQ0uv03TabviaWNxPyx+nPGXu2T1MRfya+yOHj3FKh//gc8NwRWNJvG3OQ7+2mSJkUYEe+WhvXF4tF9LJJdBFzugjLBAzHnpRruxP5RQYLXexG5IqlTYjMmfthJXWNk9fssVu3za3Il+Hul1GmVIH6I/YoXCfu6i7p2hUudaGgebkaGPP1G2QVFlplnGXGqIDTuoTkjFtLh+JaA5SsUlC13XkMX23UwqZ+S/7PuKQTF5QvcnRtQERoR3Ub/QkNqjw7AKEBBHqJYW38Vyioa6h0PpuBVLDI1N7XN6pafrHw/Rw9ljjXYtzpkMNk1oBPmjWZxHSFg79r4ag0gBXXmxVLifpI8U66a3wevTxa0wogi/BoXQUZCKqqzchQ067K1UKVDxccqJVH8xec2lvD5JOfSHMzArJMDPHyVbxkD6MHne9FUJt5yllRubQzgALRATbjf1iHCfa8DHGZQo1X8adHBV XTfcUumA XYIuNKLtRhIXPvuxwomjxa+KjO+i+CCUfAjYk01c9UoBS7gnNPHFBzGk9UMOYJQ84fwvKwq5WFOQyyRI= 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 Wed, Jul 03, 2024 at 06:51:14PM +0300, Leon Romanovsky wrote: > If we put aside this issue, do you think that the proposed API is the right one? I haven't look at it in detail yet, but from a quick look there is a few things to note: 1) The amount of code needed in nvme worries me a bit. Now NVMe a messy driver due to the stupid PRPs vs just using SGLs, but needing a fair amount of extra boilerplate code in drivers is a bit of a warning sign. I plan to look into this to see if I can help on improving it, but for that I need a working version first. 2) The amount of seemingly unrelated global headers pulled into other global headers. Some of this might just be sloppiness, e.g. I can't see why dma-mapping.h would actually need iommu.h to start with, but pci.h in dma-map-ops.h is a no-go. 3) which brings me to real layering violations. dev_is_untrusted and dev_use_swiotlb are DMA API internals, no way I'd ever want to expose them. dma-map-ops.h is a semi-internal header only for implementations of the dma ops (as very clearly documented at the top of that file), it must not be included by drivers. Same for swiotlb.h. Not quite as concerning, but doing an indirect call for each map through dma_map_ops in addition to the iommu ops is not every efficient. We've through for a while to allow direct calls to dma-iommu similar how we do direct calls to dma-direct from the core mapping.c code. This might be a good time to do that as a prep step for this work.