From: mhkelley58@gmail.com
To: kbusch@kernel.org, axboe@kernel.dk, sagi@grimberg.me,
James.Bottomley@HansenPartnership.com,
martin.petersen@oracle.com, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
robin.murphy@arm.com, hch@lst.de, m.szyprowski@samsung.com,
petr@tesarici.cz, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-coco@lists.linux.dev
Subject: [RFC 3/7] dma: Add function for drivers to know if allowing blocking is useful
Date: Thu, 22 Aug 2024 11:37:14 -0700 [thread overview]
Message-ID: <20240822183718.1234-4-mhklinux@outlook.com> (raw)
In-Reply-To: <20240822183718.1234-1-mhklinux@outlook.com>
From: Michael Kelley <mhklinux@outlook.com>
With the addition of swiotlb throttling functionality, storage
device drivers may want to know whether using the DMA_ATTR_MAY_BLOCK
attribute is useful. In a CoCo VM or environment where swiotlb=force
is used, the MAY_BLOCK attribute enables swiotlb throttling. But if
throttling is not enable or useful, storage device drivers probably
do not want to set BLK_MQ_F_BLOCKING at the blk-mq request queue level.
Add function dma_recommend_may_block() that indicates whether
the underlying implementation of the DMA map calls would benefit
from allowing blocking. If the kernel was built with
CONFIG_SWIOTLB_THROTTLE, and swiotlb=force is set (on the kernel
command line or due to being a CoCo VM), this function returns
true. Otherwise it returns false.
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
include/linux/dma-mapping.h | 5 +++++
kernel/dma/direct.c | 6 ++++++
kernel/dma/direct.h | 1 +
kernel/dma/mapping.c | 10 ++++++++++
4 files changed, 22 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 7b78294813be..ec2edf068218 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -145,6 +145,7 @@ int dma_set_mask(struct device *dev, u64 mask);
int dma_set_coherent_mask(struct device *dev, u64 mask);
u64 dma_get_required_mask(struct device *dev);
bool dma_addressing_limited(struct device *dev);
+bool dma_recommend_may_block(struct device *dev);
size_t dma_max_mapping_size(struct device *dev);
size_t dma_opt_mapping_size(struct device *dev);
unsigned long dma_get_merge_boundary(struct device *dev);
@@ -252,6 +253,10 @@ static inline bool dma_addressing_limited(struct device *dev)
{
return false;
}
+static inline bool dma_recommend_may_block(struct device *dev)
+{
+ return false;
+}
static inline size_t dma_max_mapping_size(struct device *dev)
{
return 0;
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 80e03c0838d4..34d14e4ace64 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -649,6 +649,12 @@ bool dma_direct_all_ram_mapped(struct device *dev)
check_ram_in_range_map);
}
+bool dma_direct_recommend_may_block(struct device *dev)
+{
+ return IS_ENABLED(CONFIG_SWIOTLB_THROTTLE) &&
+ is_swiotlb_force_bounce(dev);
+}
+
size_t dma_direct_max_mapping_size(struct device *dev)
{
/* If SWIOTLB is active, use its maximum mapping size */
diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
index d2c0b7e632fc..63516a540276 100644
--- a/kernel/dma/direct.h
+++ b/kernel/dma/direct.h
@@ -21,6 +21,7 @@ bool dma_direct_need_sync(struct device *dev, dma_addr_t dma_addr);
int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
enum dma_data_direction dir, unsigned long attrs);
bool dma_direct_all_ram_mapped(struct device *dev);
+bool dma_direct_recommend_may_block(struct device *dev);
size_t dma_direct_max_mapping_size(struct device *dev);
#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index b1c18058d55f..832982bafd5a 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -858,6 +858,16 @@ bool dma_addressing_limited(struct device *dev)
}
EXPORT_SYMBOL_GPL(dma_addressing_limited);
+bool dma_recommend_may_block(struct device *dev)
+{
+ const struct dma_map_ops *ops = get_dma_ops(dev);
+
+ if (dma_map_direct(dev, ops))
+ return dma_direct_recommend_may_block(dev);
+ return false;
+}
+EXPORT_SYMBOL_GPL(dma_recommend_may_block);
+
size_t dma_max_mapping_size(struct device *dev)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
--
2.25.1
next prev parent reply other threads:[~2024-08-22 18:37 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-22 18:37 [RFC 0/7] Introduce swiotlb throttling mhkelley58
2024-08-22 18:37 ` [RFC 1/7] swiotlb: " mhkelley58
2024-08-23 7:41 ` Petr Tesařík
2024-08-23 20:41 ` Michael Kelley
2024-08-27 15:55 ` Petr Tesařík
2024-08-27 17:30 ` Michael Kelley
2024-08-28 5:15 ` Petr Tesařík
2024-08-28 6:14 ` Michael Kelley
2024-08-22 18:37 ` [RFC 2/7] dma: Handle swiotlb throttling for SGLs mhkelley58
2024-08-23 8:02 ` Petr Tesařík
2024-08-23 20:42 ` Michael Kelley
2024-08-24 19:56 ` Petr Tesařík
2024-08-22 18:37 ` mhkelley58 [this message]
2024-08-23 8:07 ` [RFC 3/7] dma: Add function for drivers to know if allowing blocking is useful Petr Tesařík
2024-08-22 18:37 ` [RFC 4/7] scsi_lib_dma: Add _attrs variant of scsi_dma_map() mhkelley58
2024-08-23 8:08 ` Petr Tesařík
2024-08-22 18:37 ` [RFC 5/7] scsi: storvsc: Enable swiotlb throttling mhkelley58
2024-08-23 8:19 ` Petr Tesařík
2024-08-23 20:42 ` Michael Kelley
2024-08-22 18:37 ` [RFC 6/7] nvme: Move BLK_MQ_F_BLOCKING indicator to struct nvme_ctrl mhkelley58
2024-08-23 8:22 ` Petr Tesařík
2024-08-22 18:37 ` [RFC 7/7] nvme: Enable swiotlb throttling for NVMe PCI devices mhkelley58
2024-08-23 8:26 ` Petr Tesařík
2024-08-22 19:29 ` [RFC 0/7] Introduce swiotlb throttling Bart Van Assche
2024-08-23 2:20 ` Michael Kelley
2024-08-23 5:46 ` Petr Tesařík
2024-08-24 8:05 ` hch
2024-08-23 6:44 ` Petr Tesařík
2024-08-23 20:40 ` Michael Kelley
2024-08-24 20:05 ` Petr Tesařík
2024-08-26 16:24 ` Michael Kelley
2024-08-26 19:28 ` Petr Tesařík
2024-08-27 0:26 ` Michael Kelley
2024-08-27 8:00 ` Petr Tesařík
2024-08-24 8:16 ` Christoph Hellwig
2024-08-26 15:27 ` Michael Kelley
2024-08-27 7:14 ` Christoph Hellwig
2024-08-28 12:02 ` Robin Murphy
2024-08-28 13:03 ` Petr Tesařík
2024-08-28 16:30 ` Michael Kelley
2024-08-28 16:41 ` Petr Tesařík
2024-08-28 19:50 ` Robin Murphy
2024-08-30 3:58 ` Michael Kelley
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=20240822183718.1234-4-mhklinux@outlook.com \
--to=mhkelley58@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=axboe@kernel.dk \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=kbusch@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=martin.petersen@oracle.com \
--cc=mhklinux@outlook.com \
--cc=petr@tesarici.cz \
--cc=robin.murphy@arm.com \
--cc=sagi@grimberg.me \
--cc=wei.liu@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).