From: "Petr Tesařík" <petr@tesarici.cz>
To: mhkelley58@gmail.com
Cc: mhklinux@outlook.com, 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,
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: Re: [RFC 3/7] dma: Add function for drivers to know if allowing blocking is useful
Date: Fri, 23 Aug 2024 10:07:20 +0200 [thread overview]
Message-ID: <20240823100720.679a520f@meshulam.tesarici.cz> (raw)
In-Reply-To: <20240822183718.1234-4-mhklinux@outlook.com>
On Thu, 22 Aug 2024 11:37:14 -0700
mhkelley58@gmail.com wrote:
> 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>
LGTM.
Reviewed-by: Petr Tesarik <ptesarik@suse.com>
Petr T
> ---
> 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);
next prev parent reply other threads:[~2024-08-23 8:07 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 ` [RFC 3/7] dma: Add function for drivers to know if allowing blocking is useful mhkelley58
2024-08-23 8:07 ` Petr Tesařík [this message]
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=20240823100720.679a520f@meshulam.tesarici.cz \
--to=petr@tesarici.cz \
--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=mhkelley58@gmail.com \
--cc=mhklinux@outlook.com \
--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).