From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Jianxiong Gao <jxgao@google.com>
Cc: Keith Busch <kbusch@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
Robin Murphy <robin.murphy@arm.com>,
Dan Williams <dan.j.williams@intel.com>,
Erdem Aktas <erdemaktas@google.com>,
Vishal Annapurve <vannapurve@google.com>,
Ryan Afranji <afranji@google.com>,
linux-nvme@lists.infradead.org, iommu@lists.linux.dev
Subject: Re: [RFC PATCH 0/3] Add an option for devices to skip SWIOTLB pre-copy on read.
Date: Wed, 5 Feb 2025 09:54:21 +0200 [thread overview]
Message-ID: <Z6MZLWRv1hC8uLo1@smile.fi.intel.com> (raw)
In-Reply-To: <20250204233630.3407878-1-jxgao@google.com>
On Tue, Feb 04, 2025 at 11:36:27PM +0000, Jianxiong Gao wrote:
> Removes an extra memory copy that occurs during IO read
> operations through the SWIOTLB. During high throughput
> read workloads, this extra copy is causing a lot of stress
> on the SWIOTLB.
>
> With high performance devices, for example NVMe devices,
> the device will be overwriting the entire buffer.
Is this really guaranteed? I can imagine surprise power cut or
hotplug event, for example, just in the middle of the transfer.
> In such cases the entire pre-copy is redundent, only to slow down
> the overall bounce buffering.
>
> We propose to add a full_buffer_write flag to the
> device_dma_parameters flag. When the flag is set the pre-copy
> can be omitted to boost performance.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-02-05 7:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-04 23:36 [RFC PATCH 0/3] Add an option for devices to skip SWIOTLB pre-copy on read Jianxiong Gao
2025-02-04 23:36 ` [RFC PATCH 1/3] add full_buffer_write flag to struct device_dma_parameters Jianxiong Gao
2025-02-05 8:01 ` Andy Shevchenko
2025-02-04 23:36 ` [RFC PATCH 2/3] skip swiotlb pre copy if the device does full buffer write Jianxiong Gao
2025-02-04 23:36 ` [RFC PATCH 3/3] set full_buffer_write for nvme devices Jianxiong Gao
2025-02-05 7:54 ` Andy Shevchenko [this message]
2025-02-05 15:43 ` [RFC PATCH 0/3] Add an option for devices to skip SWIOTLB pre-copy on read Christoph Hellwig
2025-02-05 16:18 ` Keith Busch
2025-02-05 11:46 ` Robin Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z6MZLWRv1hC8uLo1@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=afranji@google.com \
--cc=axboe@kernel.dk \
--cc=dan.j.williams@intel.com \
--cc=erdemaktas@google.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=jxgao@google.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
--cc=sagi@grimberg.me \
--cc=vannapurve@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox