Received: by 2002:ab2:60d1:0:b0:1f7:5705:b850 with SMTP id i17csp1722005lqm; Fri, 3 May 2024 04:57:25 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXEe2sirhEB2Kw7VySmM7RSk4EpEa+hLyoZ+HXx2kYANsPc94rbrBTirMJ4D21kWBxSsO5wRuwPbLiF0r3V0xYUz25e+KgLYwHYmmyGnw== X-Google-Smtp-Source: AGHT+IHStYBj6O7w8/doTytCDsEHJLi3u6YpILjItpwEjFyQ3IHWEsoqaixJmpiFcxSyHDJO6d69 X-Received: by 2002:a17:906:cf83:b0:a55:75f6:ce0f with SMTP id um3-20020a170906cf8300b00a5575f6ce0fmr1515691ejb.13.1714737445522; Fri, 03 May 2024 04:57:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714737445; cv=pass; d=google.com; s=arc-20160816; b=tZxWfzATIMYQKZ5iI2ughAzt0tRPvnkQ2GIk1kSzBHXV57dxIiANhUBsTG2eBY6TIc apPJ0eBDlMDFrjG2nhkJA5LFsSNBXvlsyGg/5vo3QeeKz7wPdIrWmSZBhQl4Z0SBBYdo D3U/fah1iLXVLS9ciiIy3dzEDL1Utuv4A+oqEg0kwzY5Z5TH0rAIcPrNw5TV6JoNZUxr 7EqsbgMH6tGmAESHyIixWNJkuaJpOEu7sxdxZugY0SNyQaRd9JhUuBLF44D9jZOOwSJm GooguOfWGZSqqLdowuz8Ya3nz4Sq5Yq+OUaB0ucoII6bIQFutW87j+FqBMRsGPBkMssg ivbQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:dkim-signature:message-id; bh=QBEy7QkEaMvis9qjHZ5cOY4POeQ4rKqY2XsSXuPCu4U=; fh=deSuCIeqobhn/UyMktpN7iyfdG4gAjzBBCOgitWxwKQ=; b=pvRt78iE4Xvicc7Fdd3a+0NE672owEkQPJO0DB7bl6C4yGMCfu81QVLATYWBrM6gIv IuIqzXTwyO7XZYwVi017v0Fh8f6viPOG8t1Ll9Mq5K/sREj/Q759GxekPg5fO/MfXfFW +bPAhR5g5UaKFm779pHnUSqz0WhS3xI6Vs1hQiZ80eTHSE5Ez112oi98oX+CHzt0PjFS goJDG/oZFc8gQDdZ5ddL7TgpgbIRW+8dmd/3CSA/6996oPiRblb7dG274PXkboto4GIN +3K2KTQO7Qpi3gzN/QO43l5lW74YYf/IwbM5GH5WN/O64kFCkrvq7G9vfyzBNlwcjG4n aTtA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=qyB1ISae; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-167612-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-167612-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id a25-20020a170906245900b00a5533761bf5si1533755ejb.694.2024.05.03.04.57.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 May 2024 04:57:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-167612-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=qyB1ISae; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-167612-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-167612-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 1A2F21F22C82 for ; Fri, 3 May 2024 11:57:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8E1C51534E7; Fri, 3 May 2024 11:57:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="qyB1ISae" Received: from out-186.mta0.migadu.com (out-186.mta0.migadu.com [91.218.175.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F8AC152179 for ; Fri, 3 May 2024 11:57:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.186 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714737430; cv=none; b=GHp4x0c0n3JqF3e/1FmNf5YU12S4m7kfFzcuRmm24RHtlqvpOeFHw+hi/LWHUmfLxKpf+lQBZulfGyXVEL35WbWVyjvqY5qATGKHjBYd/UsYCPXmaAXitNmd8DS2xJ53korojVus5I7JtnDPnEnycPtWV/g4a2buXNTvOF4nFYE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714737430; c=relaxed/simple; bh=N1UR76ibJXT6KSmjP9DwgMJEalcANwTRYffmZX8HUPM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=illM0FUO26oEuE5ZoA3O+YLZ1P27E8rWI8o8/aXroOElIjh+T7ZA1liMVBE5jcJCEGMBfrQDg1DcwpjwPshUXBJ99pnLjW3EUPxFuseCrNfeN1b45qs3JmE36s1Y95Y+mcNwVjT2MeIWbhQiE6huObBZy42M4iups2BMGJ4ujp4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=qyB1ISae; arc=none smtp.client-ip=91.218.175.186 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1714737425; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QBEy7QkEaMvis9qjHZ5cOY4POeQ4rKqY2XsSXuPCu4U=; b=qyB1ISae7I/P6hByROK73LSERbiL7NzoQZuWyVzVYXd5DEKcWqZ+01n4/u2G94uRlwKdZg pgnNepE8R4vEhrgw3+TI+jbCs12NmD0KobYhO09ypdlc17huPvRqS1WfGm3a/IDhhV2Unp wPw01DbGYiFsnIgrK1nDyTpIy9Rx9YU= Date: Fri, 3 May 2024 13:57:00 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [RFC RESEND 00/16] Split IOMMU DMA mapping operation to two steps To: "Zeng, Oak" , "leon@kernel.org" , Christoph Hellwig , Robin Murphy , Marek Szyprowski , Joerg Roedel , Will Deacon , Jason Gunthorpe , Chaitanya Kulkarni , "Brost, Matthew" , "Hellstrom, Thomas" Cc: Jonathan Corbet , Jens Axboe , Keith Busch , Sagi Grimberg , Yishai Hadas , Shameer Kolothum , "Tian, Kevin" , Alex Williamson , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Andrew Morton , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "iommu@lists.linux.dev" , "linux-nvme@lists.infradead.org" , "kvm@vger.kernel.org" , "linux-mm@kvack.org" , Bart Van Assche , Damien Le Moal , Amir Goldstein , "josef@toxicpanda.com" , "Martin K. Petersen" , "daniel@iogearbox.net" , "Williams, Dan J" , "jack@suse.com" , Leon Romanovsky References: Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Zhu Yanjun In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 03.05.24 01:32, Zeng, Oak wrote: > Hi Leon, Jason > >> -----Original Message----- >> From: Leon Romanovsky >> Sent: Tuesday, March 5, 2024 6:19 AM >> To: Christoph Hellwig ; Robin Murphy >> ; Marek Szyprowski >> ; Joerg Roedel ; Will >> Deacon ; Jason Gunthorpe ; Chaitanya >> Kulkarni >> Cc: Jonathan Corbet ; Jens Axboe ; >> Keith Busch ; Sagi Grimberg ; >> Yishai Hadas ; Shameer Kolothum >> ; Kevin Tian >> ; Alex Williamson ; >> Jérôme Glisse ; Andrew Morton > foundation.org>; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; >> linux-block@vger.kernel.org; linux-rdma@vger.kernel.org; >> iommu@lists.linux.dev; linux-nvme@lists.infradead.org; >> kvm@vger.kernel.org; linux-mm@kvack.org; Bart Van Assche >> ; Damien Le Moal >> ; Amir Goldstein >> ; josef@toxicpanda.com; Martin K. Petersen >> ; daniel@iogearbox.net; Dan Williams >> ; jack@suse.com; Leon Romanovsky >> ; Zhu Yanjun >> Subject: [RFC RESEND 00/16] Split IOMMU DMA mapping operation to two >> steps >> >> This is complimentary part to the proposed LSF/MM topic. >> https://lore.kernel.org/linux-rdma/22df55f8-cf64-4aa8-8c0b- >> b556c867b926@linux.dev/T/#m85672c860539fdbbc8fe0f5ccabdc05b40269057 >> >> This is posted as RFC to get a feedback on proposed split, but RDMA, VFIO >> and >> DMA patches are ready for review and inclusion, the NVMe patches are still >> in >> progress as they require agreement on API first. >> >> Thanks >> >> ------------------------------------------------------------------------------- >> The DMA mapping operation performs two steps at one same time: allocates >> IOVA space and actually maps DMA pages to that space. This one shot >> operation works perfectly for non-complex scenarios, where callers use >> that DMA API in control path when they setup hardware. >> >> However in more complex scenarios, when DMA mapping is needed in data >> path and especially when some sort of specific datatype is involved, >> such one shot approach has its drawbacks. >> >> That approach pushes developers to introduce new DMA APIs for specific >> datatype. For example existing scatter-gather mapping functions, or >> latest Chuck's RFC series to add biovec related DMA mapping [1] and >> probably struct folio will need it too. >> >> These advanced DMA mapping APIs are needed to calculate IOVA size to >> allocate it as one chunk and some sort of offset calculations to know >> which part of IOVA to map. >> >> Instead of teaching DMA to know these specific datatypes, let's separate >> existing DMA mapping routine to two steps and give an option to advanced >> callers (subsystems) perform all calculations internally in advance and >> map pages later when it is needed. > I looked into how this scheme can be applied to DRM subsystem and GPU drivers. > > I figured RDMA can apply this scheme because RDMA can calculate the iova size. Per my limited knowledge of rdma, user can register a memory region (the reg_user_mr vfunc) and memory region's sized is used to pre-allocate iova space. And in the RDMA use case, it seems the user registered region can be very big, e.g., 512MiB or even GiB > > In GPU driver, we have a few use cases where we need dma-mapping. Just name two: > > 1) userptr: it is user malloc'ed/mmap'ed memory and registers to gpu (in Intel's driver it is through a vm_bind api, similar to mmap). A userptr can be of any random size, depending on user malloc size. Today we use dma-map-sg for this use case. The down side of our approach is, during userptr invalidation, even if user only munmap partially of an userptr, we invalidate the whole userptr from gpu page table, because there is no way for us to partially dma-unmap the whole sg list. I think we can try your new API in this case. The main benefit of the new approach is the partial munmap case. > > We will have to pre-allocate iova for each userptr, and we have many userptrs of random size... So we might be not as efficient as RDMA case where I assume user register a few big memory regions. > > 2) system allocator: it is malloc'ed/mmap'ed memory be used for GPU program directly, without any other extra driver API call. We call this use case system allocator. > > For system allocator, driver have no knowledge of which virtual address range is valid in advance. So when GPU access a malloc'ed/mmap'ed address, we have a page fault. We then look up a CPU vma which contains the fault address. I guess we can use the CPU vma size to allocate the iova space of the same size? > > But there will be a true difficulty to apply your scheme to this use case. It is related to the STICKY flag. As I understand it, the sticky flag is designed for driver to mark "this page/pfn has been populated, no need to re-populate again", roughly...Unlike userptr and RDMA use cases where the backing store of a buffer is always in system memory, in the system allocator use case, the backing store can be changing b/t system memory and GPU's device private memory. Even worse, we have to assume the data migration b/t system and GPU is dynamic. When data is migrated to GPU, we don't need dma-map. And when migration happens to a pfn with STICKY flag, we still need to repopulate this pfn. So you can see, it is not easy to apply this scheme to this use case. At least I can't see an obvious way. Not sure if GPU peer to peer dma mapping GPU memory for use can use this scheme or not. If I remember it correctly, Intel Gaudi GPU supports peer 2 peer dma mapping in GPU Direct RDMA. Not sure if this scheme can be applied in that place or not. Just my 2 cent suggestions. Zhu Yanjun > > > Oak > > >> In this series, three users are converted and each of such conversion >> presents different positive gain: >> 1. RDMA simplifies and speeds up its pagefault handling for >> on-demand-paging (ODP) mode. >> 2. VFIO PCI live migration code saves huge chunk of memory. >> 3. NVMe PCI avoids intermediate SG table manipulation and operates >> directly on BIOs. >> >> Thanks >> >> [1] >> https://lore.kernel.org/all/169772852492.5232.17148564580779995849.stgit@ >> klimt.1015granger.net >> >> Chaitanya Kulkarni (2): >> block: add dma_link_range() based API >> nvme-pci: use blk_rq_dma_map() for NVMe SGL >> >> Leon Romanovsky (14): >> mm/hmm: let users to tag specific PFNs >> dma-mapping: provide an interface to allocate IOVA >> dma-mapping: provide callbacks to link/unlink pages to specific IOVA >> iommu/dma: Provide an interface to allow preallocate IOVA >> iommu/dma: Prepare map/unmap page functions to receive IOVA >> iommu/dma: Implement link/unlink page callbacks >> RDMA/umem: Preallocate and cache IOVA for UMEM ODP >> RDMA/umem: Store ODP access mask information in PFN >> RDMA/core: Separate DMA mapping to caching IOVA and page linkage >> RDMA/umem: Prevent UMEM ODP creation with SWIOTLB >> vfio/mlx5: Explicitly use number of pages instead of allocated length >> vfio/mlx5: Rewrite create mkey flow to allow better code reuse >> vfio/mlx5: Explicitly store page list >> vfio/mlx5: Convert vfio to use DMA link API >> >> Documentation/core-api/dma-attributes.rst | 7 + >> block/blk-merge.c | 156 ++++++++++++++ >> drivers/infiniband/core/umem_odp.c | 219 +++++++------------ >> drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + >> drivers/infiniband/hw/mlx5/odp.c | 59 +++-- >> drivers/iommu/dma-iommu.c | 129 ++++++++--- >> drivers/nvme/host/pci.c | 220 +++++-------------- >> drivers/vfio/pci/mlx5/cmd.c | 252 ++++++++++++---------- >> drivers/vfio/pci/mlx5/cmd.h | 22 +- >> drivers/vfio/pci/mlx5/main.c | 136 +++++------- >> include/linux/blk-mq.h | 9 + >> include/linux/dma-map-ops.h | 13 ++ >> include/linux/dma-mapping.h | 39 ++++ >> include/linux/hmm.h | 3 + >> include/rdma/ib_umem_odp.h | 22 +- >> include/rdma/ib_verbs.h | 54 +++++ >> kernel/dma/debug.h | 2 + >> kernel/dma/direct.h | 7 +- >> kernel/dma/mapping.c | 91 ++++++++ >> mm/hmm.c | 34 +-- >> 20 files changed, 870 insertions(+), 605 deletions(-) >> >> -- >> 2.44.0 -- Best Regards, Yanjun.Zhu