From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B1223C5DC3 for ; Mon, 4 May 2026 15:30:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777908617; cv=none; b=pL8fHvh4s6F9SUMZ+23UZVEirpdPiIKa7QlsTG/2XX69J5b+QTOvRRxVIb0mrDcddjX0PP92J9xcd4+AhUAUaJM1MFYe78Uve/ZYGdB/c+GqTjl8eWsy9YNDLJM9E/KJRgfjR3UJVJlwTtJ5E4YCKrtrKdy3Nn/epFIVb73PcC4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777908617; c=relaxed/simple; bh=6QwUQCcZs6tvnhRhV82Gt4iwhALrIcfYYBRUBpS70Xk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rl6p0gUqxibx7tIPeS8hmm9jEaSyNbFvNxfSF7VLbEXtP6nmghkOueZyxNW/rxIbaQoYamqp/rTOuvH3LN7wjJeBKTsbrR4Rd6fwPtwjo/wvDm7vrhXxO+lskNES1rC5CghiSzJ8tZc2gAFMebsjS0TOX9LD7Nllew6wzwaM9T8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=KRCydiHt; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KRCydiHt" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-488b0046078so34723625e9.1 for ; Mon, 04 May 2026 08:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777908615; x=1778513415; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=JTReAJBRtrEN050pOinCvG1qLugpFlFxRiDBF5vEgm4=; b=KRCydiHtndzdGf5TkyPWPK008OR44tmdTzRSw2JTkci3b8zxWdo6LUsffiYnvHOIHZ byvbAFU+RxD4lCtq0X+S2IM4H0QbB6OZMCBxc7pin9y6EX+SuPXA5gMhhWyeXfpWAAV2 Ks2/rvJXblg6QPna/4dBmIaDduBtVsMUv7M+b8K74EgNRC5F6jdMSS0X6eDO4NIB2O8E FByWC3qNVSk5GNL8bwbGWbQyiohl2FuRsikc2DbQXJqAFZMniHDWsJjhrCZRbrQpJSz+ eFYbBUm/AxpKp0NDVg0mO4O7XcgZ22nVwUnW81OZx2sRwS1e6QUjjoB+WkcRsrYrQtxs dBJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777908615; x=1778513415; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JTReAJBRtrEN050pOinCvG1qLugpFlFxRiDBF5vEgm4=; b=WwPDmxgMIX6Msg/IovUoiJFPLXQ+E2CQmst2FARcbqpsfT4BGuOgzwkDJvxXDTaSa+ yYYMcLonXna0RD/J+G6OXrh7rVsiWDvQWmkqYuT8UnbrY8FvrTSWprFCO+wAzXH5WgjF o8SPtUUa8W0j4UiKF/qV+lg1IU3x8mWADfYtEYpW7R6puAoSl3R4GNOFk0yhMhsHFwT2 xXz9igTKLDxo8of2Y1eKkuxabpaRTbAHaqyGwtwKSgcighLhfcEbalP8Mokt+B11gJi4 iOtVJAY1QynAnyihIHFUZfIWVElHMGgweTnyx+3OuNBRJxToE5/AQZznUqeQCCdLLiKk mTUw== X-Forwarded-Encrypted: i=1; AFNElJ+gvz6F/wHq5sHFM1RkYmEnxmZAAb5sdbtngZ/rAhfU/ZQ5ehkASgfNm+XttbDXcByaWYfSE0Qsv0WNdxM=@vger.kernel.org X-Gm-Message-State: AOJu0Yz1SGbEdy8oW9ptda2iO2gKRtQ0XX0T0oKx1cxy8lmCqQybPioQ 9+NeB5PJPFKGQ/24CcwwBqKLUS3FKvOeVgbLUqG1mPBi9MfdMzhxwkks X-Gm-Gg: AeBDiev3emdwnN9Uh0P6rm/lP/SR3l/FTaF9/XzBJBn1xGiHP4cSQRjYFdHC2qEU+6Q QOkivX01LE78DpqRJF/WtfQXhfa9eeF7a4zlzeVUlse3rE3DsDD9E+GlzqDblw0hVVvQwA+E5og 4D+/wZ2ByMP9vtQvcKwFgiMsLYTcVTPFwTx5DLyCOhSAMrGFgvz9J4TtDVGqQ9MwGMHIOgy+TFO W7hfrRsKFVOr0o1Qe7S4u1Gtfh8Nhh731oi+YxTyEWjvkkxpQOUA/XTI3y6Z+CEzNmxHiU2Z+ka iW9GicirvN47aweqHidvMY0lD/YH7fPhO6Vq5dnH1F9TAzZ4KdhQyD7edP43yjEPI684lwVWA24 vYZ4opbd1IiBNyp7qCp4t2Hv+Tqm7YgjqRsMbx+reCdbm1MTUUIAb+3xzf3AvGkzaXB1/aDSRTA muwvwaNG9f3VKS+lNmv7XHlCUihuifXT3KcyV1zoogQiC7lhr5tQNQJOpddUNFqkJowhXefcN6R LK7cRO8lmkqpxLWdAPce81i X-Received: by 2002:a05:600c:4f91:b0:489:1ba8:5be9 with SMTP id 5b1f17b1804b1-48a98676b26mr157938505e9.29.1777908614504; Mon, 04 May 2026 08:30:14 -0700 (PDT) Received: from fedora (185-147-212-251.par.as62651.net. [185.147.212.251]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-44a8ea7cfd2sm25250825f8f.2.2026.05.04.08.30.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2026 08:30:13 -0700 (PDT) Date: Mon, 4 May 2026 23:29:55 +0800 From: Ming Lei To: Pavel Begunkov Cc: Jens Axboe , Keith Busch , Christoph Hellwig , Sagi Grimberg , Alexander Viro , Christian Brauner , Andrew Morton , Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, Nitesh Shetty , Kanchan Joshi , Anuj Gupta , Tushar Gohad , William Power , Phil Cayton , Jason Gunthorpe Subject: Re: [PATCH v3 00/10] Add dmabuf read/write via io_uring Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Apr 29, 2026 at 04:25:46PM +0100, Pavel Begunkov wrote: > The patch set allows to register a dmabuf to an io_uring instance for > a specified file and use it with io_uring read / write requests. The > infrastructure is not tied to io_uring and there could be more users > in the future. A similar idea was attempted some years ago by Keith [1], > from where I borrowed a good number of changes, and later was brough up > by Tushar and Vishal from Intel. > > It's an opt-in feature for files, and they need to implement a new > file operation to use it. Only NVMe block devices are supported in this > series. The user API is built on top of io_uring's "registered buffers", > where a dmabuf is registered in a special way, but after it can be used > as any other "registered buffer" with IORING_OP_{READ,WRITE}_FIXED > requests. It's created via a new file operation and the resulted map is > then passed through the I/O stack in a new iterator type. There is some > additional infrastructure to bind it all, which also counts requests > using a dmabuf map and managing lifetimes, which is used to implement > map invalidation. > > It was tested for GPU <-> NVMe transfers. Also, as it maintains a > long-term dma mapping, it helps with the IOMMU cost. The numbers > below are for udmabuf reads previously run by Anuj for different > IOMMU modes: Plain registered buffer is long-live too, which raises question: does this framework need to take it into account from beginning? BTW, inspired by this approach, I adds similar feature to ublk via UBLK_IO_F_SHMEM_ZC which can maintain long-term vfio dma mapping over registered user-place aligned buffer. Thanks, Ming