Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1289253pxb; Fri, 21 Jan 2022 14:28:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJy8TyyBQ7SPZuB5eLY7/pdaOaPkFTlsmr2ayMYgNPo7wpfHrm6ikLQ72EzNRFjcmmv5k7hT X-Received: by 2002:a17:90b:380f:: with SMTP id mq15mr2717594pjb.16.1642804118760; Fri, 21 Jan 2022 14:28:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642804118; cv=none; d=google.com; s=arc-20160816; b=LaEaGGo1Prho4ygM2kvRaE8lpPgpQqf1SSqB0SVXUxyF5rPguPZgB3IRaN/0fpQab6 Q4ZMgQPK7kMN9HRsBoju5VL/EHgVaNc6ALYtYuhS3wK90NlR8uxekbC6ovB1idz6fGSE w0PK+kTZFJmq+0tPE1bHEW5l087TmiV0mQJGTa+T+QI/em4l7uQHGGROycnzW7GvJn7b Hc1Xoj4LVayydNbi3tBbecT87or+YKiNQFJcjMCxI292V6JhQuzmwN/NUn5XiV3x9EIC HXYDYvLzmGdQKsOMg3NCgNzrsZ/PZIbYqe/M05KNTMHHkuh3EwzRiRP1LTxXOgOM1hzA WJWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=NB68ldpD6FJ21wcbP7Bwc8DkLeNCtDnqn2PS2oMx9iQ=; b=kCMkzL8+1c4qbaiIWmELwgkcMEJTsjJBQjs08SPQ95QWFi4X1t/byvb/V5v1HiY6a5 C5qntoyArUyfYmSKA2nU83otZ80j+YQl64t9C00a0wBQBdLXJPU6En49TZnvHqYlM58V wxw0XTY+T0yQqWlxQkToJA5NQM4XiVt8qYK+0TeKoRRrMV3Xm7gs6TESaMmJrZHg8hzt kTaTkg8yN4bm7KArm9tFamBA5zih0DLOiNdy1PEJO2S/YCBvv3CRpT6xgr0WycwsEtsM MBXF94EcmyBvtxY9I0erxELRqRhUs22vIw5obGqeTczVc4Vskpz+zxzlboSkkTuoLcZX 3L5A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e7si6648371pjd.32.2022.01.21.14.28.25; Fri, 21 Jan 2022 14:28:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233013AbiATRyq (ORCPT + 99 others); Thu, 20 Jan 2022 12:54:46 -0500 Received: from foss.arm.com ([217.140.110.172]:47074 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232979AbiATRyi (ORCPT ); Thu, 20 Jan 2022 12:54:38 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3F09FED1; Thu, 20 Jan 2022 09:54:37 -0800 (PST) Received: from [10.57.68.26] (unknown [10.57.68.26]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0213C3F774; Thu, 20 Jan 2022 09:54:34 -0800 (PST) Message-ID: <744d247c-bbb5-80aa-f774-c65791cb0766@arm.com> Date: Thu, 20 Jan 2022 17:54:30 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Phyr Starter Content-Language: en-GB To: Keith Busch , Christoph Hellwig Cc: nvdimm@lists.linux.dev, linux-rdma@vger.kernel.org, John Hubbard , linux-kernel@vger.kernel.org, Matthew Wilcox , Ming Lei , linux-block@vger.kernel.org, linux-mm@kvack.org, dri-devel@lists.freedesktop.org, Jason Gunthorpe , netdev@vger.kernel.org, Joao Martins , Logan Gunthorpe References: <20220111004126.GJ2328285@nvidia.com> <20220120135602.GA11223@lst.de> <20220120152736.GB383746@dhcp-10-100-145-180.wdc.com> From: Robin Murphy In-Reply-To: <20220120152736.GB383746@dhcp-10-100-145-180.wdc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-01-20 15:27, Keith Busch wrote: > On Thu, Jan 20, 2022 at 02:56:02PM +0100, Christoph Hellwig wrote: >> - on the input side to dma mapping the bio_vecs (or phyrs) are chained >> as bios or whatever the containing structure is. These already exist >> and have infrastructure at least in the block layer >> - on the output side I plan for two options: >> >> 1) we have a sane IOMMU and everyting will be coalesced into a >> single dma_range. This requires setting the block layer >> merge boundary to match the IOMMU page size, but that is >> a very good thing to do anyway. > > It doesn't look like IOMMU page sizes are exported, or even necessarily > consistently sized on at least one arch (power). FWIW POWER does its own thing separate from the IOMMU API. For all the regular IOMMU API players, page sizes are published in the iommu_domain that the common iommu-dma layer operates on. In fact it already uses them to pick chunk sizes for composing large buffer allocations. Robin.