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 147ABC2BD09 for ; Fri, 12 Jul 2024 04:54:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42DB46B008A; Fri, 12 Jul 2024 00:54:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B5E06B0093; Fri, 12 Jul 2024 00:54:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A5026B0095; Fri, 12 Jul 2024 00:54:31 -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 093B46B008A for ; Fri, 12 Jul 2024 00:54:31 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7DFC11A0929 for ; Fri, 12 Jul 2024 04:54:30 +0000 (UTC) X-FDA: 82329884700.15.1EA1C48 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf07.hostedemail.com (Postfix) with ESMTP id 9D09C4000C for ; Fri, 12 Jul 2024 04:54:28 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf07.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=1720760036; 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=hdkSprgXz1TOuzpRa551TU4TlZl7jkQZWLDN1cGr7Gs=; b=jInnZDIB5grF2kUn1bVjkEJBJdcD3Bwfh2Bc5mkahaIM+OSw4TjQqzrhUOMNGhH2Qjurbn fRBEFu3C7/llsa3l/lQ+ojM36GgnUH7M55Lu7cJMqQOiokQaqUFy/AtcGUlZv546HU4BUV J0zE6bvgD5UgMEP/nc4JEwMRKUSaJ/M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720760036; a=rsa-sha256; cv=none; b=cdtQjhvLXCudrSpBej3GG4ftjRpW3/pfO9LdCENYqiQ0demTVBmaz49l19wJfH2f0rvN/6 dU3xTgw9xkyHKWwp9DvNqVuaWOWle3pFij9tuhCqVkf6CeOnXtzBv6yXQblmBTMwWurHIj FD0kyyeBdWVfDEwudbI6l5z6bL9ccm4= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf07.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 1F8DD68BEB; Fri, 12 Jul 2024 06:54:23 +0200 (CEST) Date: Fri, 12 Jul 2024 06:54:22 +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: <20240712045422.GA4774@lst.de> References: <20240705063910.GA12337@lst.de> <20240708235721.GF14050@ziepe.ca> <20240709062015.GB16180@lst.de> <20240709190320.GN14050@ziepe.ca> <20240710062212.GA25895@lst.de> <20240711232917.GR14050@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240711232917.GR14050@ziepe.ca> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Queue-Id: 9D09C4000C X-Stat-Signature: ujuzh5zqsij9fg9szzwridcwf819p54m X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1720760068-17611 X-HE-Meta: U2FsdGVkX18AyCaIspEGN+G0/3+tMro8mkxl2AA+0mwMd6ace9t85jObZ4wXBQ8GBwE8tPPfFxR94+QGhG8JFKWklHeKi6sOaBAUKeF630DTDZrNuJDBwBz02mh3bpc4zruMOrUUfSPY8xeLqubu2UwrIUD5ycKfpGyo5pOOvJNeija8ENIsKKMqbQX83cskbKrjeaNm7MX/xNmN+FegX11Cf0pBmD47/4sptMTh8/Si/JfkA4Mw45pxEdQgy1GeytXThmSwGrRN1C4LvYgCaGjiM2uxV89TT2kJaurt722c+C252GYuvnQMBwFaM2uXnIMhtRn6dkP2A9YROZfW0C8L2+7OLn0nlN2poXbxGdren/EDRq77bd7aNzmzP/wS5f29106fhXdaCx/yZ/O2BRLTQwcKMtFaKSH2btKTvBouoqUrxwzK2ZzhP1jP4bUpBC52kw9CbTvNDeddI568jlpXmoUhFEqekg0tupgwNvFi5ZeewacnFPVFKBIKaX8utklWNaiZH+UX2iP6eLgakdAXldkyZCwKoWYcsAHqJLmbLvBgzNbpcq1pygDgWpQn/9fV9kqYk9QUXeq/S0Sx4tNpW/akMc+S1L9hl0CcwT1XufDPZ7+3uQdgNCzNw+E63tD8MstSQyVmf400tZwcKTy2nPC6yoUJhS0KBcPq/9BCzP4CDqgpHrcEXYEuvY7BGrIY91IJMvEQ91LCHAtIVZ8wC01NDY7TzeRAPJNW2rYYs7dRoUbTQLLReQ35fvni3S7OyM2gY0ktzlCry4f/ngfivalNDvk0/vR2zYMuESoOeB6OP8m94ZZcNzlFGLblab+3eDsnIocxbtz46T4gfi5jjPPMxHGssCCSC3dfQdWKc9TJGb6cmfRvJfw4GjE4SN/6Jn8m917AQjaHqN96+5px3RyHftRZu882aukGBVkHW/WA5c63kg5ZDYeFFApJym/zxRo35mEVzmXEYO3 grRibTW2 xjsCfrL4nzqUGmaM+djiHkLTXBHCMG7CGbj2KsaGAMYzdkYxazmRapLF5FnAZkQ/6yf7tlyVXD2LcygE= 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 Thu, Jul 11, 2024 at 08:29:17PM -0300, Jason Gunthorpe wrote: > So this little detail needs to be taken care of somehow as well, and I > didn't see it in this RFC. Yes. Same about generally not mixing P2P and non-P2P. > > > For the block layer just having one kind per BIO is fine right now, > > although I could see use cases where people would want to combine > > them. We can probably defer that until it is needed, though. > > Do you have an application in mind that would want multi-kind per BIO? If you are doing say garbage collection in a file system, and do write that sources data from multiple devices, where some sit directly on the root port and others behind a switch. This is all purely hypothetical, and I'm happy to just check for it and reject it for it now.