On Mon, 1 Jul 2024 06:36:15 +0200
"h...@lst.de" wrote:
> On Sun, Jun 30, 2024 at 02:02:52PM +, Michael Kelley wrote:
> > 1) Rename is_swiotlb_buffer() to swiotlb_find_pool(), since it
> > now returns a pool. A NULL return value indicates that the
> > paddr is not an swiotlb buffer.
> >
> >
On Sun, Jun 30, 2024 at 02:02:52PM +, Michael Kelley wrote:
> 1) Rename is_swiotlb_buffer() to swiotlb_find_pool(), since it
> now returns a pool. A NULL return value indicates that the
> paddr is not an swiotlb buffer.
>
> 2) Similarly, rename is_xen_swiotlb_buffer() to
> xen_swiotlb_find_po
From: h...@lst.de Sent: Saturday, June 29, 2024 10:56 PM
>
> On Sat, Jun 29, 2024 at 03:55:58PM +, Michael Kelley wrote:
> > Unless there is further discussion on this point, I'll just keep the
> > original
> > "is_swiotlb_buffer()" in v2.
>
> That is the wrong name for something that retur
On Sat, Jun 29, 2024 at 03:55:58PM +, Michael Kelley wrote:
> Unless there is further discussion on this point, I'll just keep the original
> "is_swiotlb_buffer()" in v2.
That is the wrong name for something that returns the pool as pointed
out before.
From: Petr Tesařík Sent: Friday, June 28, 2024 12:47 AM
>
> V Fri, 28 Jun 2024 08:01:29 +0200
> "h...@lst.de" napsáno:
>
> > On Thu, Jun 27, 2024 at 04:02:59PM +, Michael Kelley wrote:
> > > > > Conceptually, it's still being used as a boolean function based on
> > > > > whether the return
From: Michael Kelley Sent: Thursday, June 27, 2024 8:05
AM
>
> From: Petr Tesařík Sent: Thursday, June 27, 2024 12:21 AM
>
> [...]
>
> > > @@ -187,10 +169,13 @@ static inline bool is_swiotlb_buffer(struct device
> > > *dev, phys_addr_t paddr)
> > >* This barrier pairs with smp_mb() in sw
V Fri, 28 Jun 2024 08:01:29 +0200
"h...@lst.de" napsáno:
> On Thu, Jun 27, 2024 at 04:02:59PM +, Michael Kelley wrote:
> > > > Conceptually, it's still being used as a boolean function based on
> > > > whether the return value is NULL. Renaming it to swiotlb_get_pool()
> > > > more accuratel
On Thu, Jun 27, 2024 at 04:02:59PM +, Michael Kelley wrote:
> > > Conceptually, it's still being used as a boolean function based on
> > > whether the return value is NULL. Renaming it to swiotlb_get_pool()
> > > more accurately describes the return value, but obscures the
> > > intent of dete
From: h...@lst.de Sent: Thursday, June 27, 2024 8:25 AM
>
> On Thu, Jun 27, 2024 at 02:59:03PM +, Michael Kelley wrote:
> > Conceptually, it's still being used as a boolean function based on
> > whether the return value is NULL. Renaming it to swiotlb_get_pool()
> > more accurately describes
On Thu, Jun 27, 2024 at 02:59:03PM +, Michael Kelley wrote:
> Conceptually, it's still being used as a boolean function based on
> whether the return value is NULL. Renaming it to swiotlb_get_pool()
> more accurately describes the return value, but obscures the
> intent of determining if it is
From: Petr Tesařík Sent: Thursday, June 27, 2024 12:21 AM
[...]
> > @@ -187,10 +169,13 @@ static inline bool is_swiotlb_buffer(struct device
> > *dev, phys_addr_t paddr)
> > * This barrier pairs with smp_mb() in swiotlb_find_slots().
> > */
> > smp_rmb();
> > - return READ_ONCE(
From: Petr Tesařík Sent: Wednesday, June 26, 2024 11:52 PM
>
> Oh, right. The idea is good, but I was not able to reply immediately
> and then forgot about it.
>
> For the record, I considered an alternative: Call swiotlb_* functions
> unconditionally and bail out early if the pool is NULL. But
On Thu, 6 Jun 2024 20:14:21 -0700
mhkelle...@gmail.com wrote:
> 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 mus
On Thu, 27 Jun 2024 08:02:51 +0200
"h...@lst.de" wrote:
> On Wed, Jun 26, 2024 at 11:58:13PM +, Michael Kelley wrote:
> > > This patch trades off making many of the core swiotlb APIs take
> > > an additional argument in order to avoid duplicating calls to
> > > swiotlb_find_pool(). The curren
On Wed, Jun 26, 2024 at 11:58:13PM +, Michael Kelley wrote:
> > This patch trades off making many of the core swiotlb APIs take
> > an additional argument in order to avoid duplicating calls to
> > swiotlb_find_pool(). The current code seems rather wasteful in
> > making 6 calls per round-trip,
From: mhkelle...@gmail.com Sent: Thursday, June 6, 2024
8:14 PM
>
> 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
16 matches
Mail list logo
