On Sun, 7 Jul 2024 02:11:48 +
Michael Kelley wrote:
> From: Christoph Hellwig Sent: Friday, July 5, 2024 10:50 PM
> >
> > Hi Michael,
> >
> > I like the idea behind this, but can you respin it to avoid some of
> > the added code duplication. We have a lot of this pattern:
> >
> > poo
On Sun, Jul 07, 2024 at 02:11:48AM +, Michael Kelley wrote:
> This works pretty well. It certainly avoids the messiness of declaring
> a "pool" local variable and needing a separate assignment before the
> "if" statement, in each of the 9 call sites. The small downside is that
> it looks like a
From: Michael Kelley Sent: Saturday, July 6, 2024 7:12 PM
[ ... ]
> >
> > If we then stub out swiotlb_find_pool to return NULL for !CONFIG_SWIOTLB,
> > we also don't need extra stubs for all the __swiotlb_ helpers as the
> > compiler will eliminate the calls as dead code.
>
> Yes, this works as l
From: Christoph Hellwig Sent: Friday, July 5, 2024 10:50 PM
>
> Hi Michael,
>
> I like the idea behind this, but can you respin it to avoid some of
> the added code duplication. We have a lot of this pattern:
>
> pool = swiotlb_find_pool(dev, paddr);
> if (pool)
> swi
Hi Michael,
I like the idea behind this, but can you respin it to avoid some of
the added code duplication. We have a lot of this pattern:
pool = swiotlb_find_pool(dev, paddr);
if (pool)
swiotlb_foo(dev, ...
duplicated in all three swiotlb users. If we rename
From: Michael Kelley
With CONFIG_SWIOTLB_DYNAMIC enabled, each round-trip map/unmap pair
in the swiotlb results in 6 calls to swiotlb_find_pool(). In multiple
places, the pool is found and used in one function, and then must
found again in the next function that is called because only the
tlb_add
