diff mbox series

[v4,05/18] dma-mapping: Add check if IOVA can be used

Message ID b23a1e29f00f31f31641479c90f2471aee27fac5.1733398913.git.leon@kernel.org (mailing list archive)
State Superseded
Headers show
Series Provide a new two step DMA mapping API | expand

Commit Message

Leon Romanovsky Dec. 5, 2024, 1:21 p.m. UTC
From: Leon Romanovsky <leonro@nvidia.com>

This patch adds a check if IOVA can be used for the specific
transaction.

In the new API a DMA mapping transaction is identified by a
struct dma_iova_state, which holds some recomputed information
for the transaction which does not change for each page being
mapped.

Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 include/linux/dma-mapping.h | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

Comments

Christoph Hellwig Dec. 12, 2024, 8:34 a.m. UTC | #1
On Thu, Dec 05, 2024 at 03:21:04PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
> 
> This patch adds a check if IOVA can be used for the specific
> transaction.
> 
> In the new API a DMA mapping transaction is identified by a
> struct dma_iova_state, which holds some recomputed information
> for the transaction which does not change for each page being
> mapped.

While the content of the patch here looks fine, the super fine
grained patch split look really odd and makes sensible review
hard.  Was this a request on one of the earlier versions?
Leon Romanovsky Dec. 12, 2024, 8:45 a.m. UTC | #2
On Thu, Dec 12, 2024 at 09:34:59AM +0100, Christoph Hellwig wrote:
> On Thu, Dec 05, 2024 at 03:21:04PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> > 
> > This patch adds a check if IOVA can be used for the specific
> > transaction.
> > 
> > In the new API a DMA mapping transaction is identified by a
> > struct dma_iova_state, which holds some recomputed information
> > for the transaction which does not change for each page being
> > mapped.
> 
> While the content of the patch here looks fine, the super fine
> grained patch split look really odd and makes sensible review
> hard.  Was this a request on one of the earlier versions?

I don't think so. It is combination of two factors:
1. Review cycles, which caused to shrink this patch.
For example, see the amount of content in RFC version of same patch
https://lore.kernel.org/all/cac154df7131984929a1cf73948bc5986af5ef85.1726138681.git.leon@kernel.org/
2. Attempt to localize changes in dma-mapping.h file. The following
patch touches dma-iommu.c, while this doesn't need to do so.

I can squash them.

Thanks
diff mbox series

Patch

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index b79925b1c433..0d1fc0a2fc0f 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -72,6 +72,20 @@ 
 
 #define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
 
+struct dma_iova_state {
+	size_t __size;
+};
+
+/*
+ * Use the high bit to mark if we used swiotlb for one or more ranges.
+ */
+#define DMA_IOVA_USE_SWIOTLB		(1ULL << 63)
+
+static inline size_t dma_iova_size(struct dma_iova_state *state)
+{
+	return state->__size & ~DMA_IOVA_USE_SWIOTLB;
+}
+
 #ifdef CONFIG_DMA_API_DEBUG
 void debug_dma_mapping_error(struct device *dev, dma_addr_t dma_addr);
 void debug_dma_map_single(struct device *dev, const void *addr,
@@ -277,6 +291,25 @@  static inline int dma_mmap_noncontiguous(struct device *dev,
 }
 #endif /* CONFIG_HAS_DMA */
 
+#ifdef CONFIG_IOMMU_DMA
+/**
+ * dma_use_iova - check if the IOVA API is used for this state
+ * @state: IOVA state
+ *
+ * Return %true if the DMA transfers uses the dma_iova_*() calls or %false if
+ * they can't be used.
+ */
+static inline bool dma_use_iova(struct dma_iova_state *state)
+{
+	return state->__size != 0;
+}
+#else /* CONFIG_IOMMU_DMA */
+static inline bool dma_use_iova(struct dma_iova_state *state)
+{
+	return false;
+}
+#endif /* CONFIG_IOMMU_DMA */
+
 #if defined(CONFIG_HAS_DMA) && defined(CONFIG_DMA_NEED_SYNC)
 void __dma_sync_single_for_cpu(struct device *dev, dma_addr_t addr, size_t size,
 		enum dma_data_direction dir);