On Sun, 2 Oct 2022 at 19:00, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Sat, Oct 1, 2022 at 3:30 PM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > > > The "force bouncing" in my series currently only checks for small > > (potentially kmalloc'ed) sizes under the assumption that intra-object > > DMA buffers were properly aligned to 128. So for something like below: > > Ahh, so your forced bouncing isn't actually safe. > > I would have hoped (but obviously never checked) that the force > bouncing be made really safe and look at the actual alignment of the > DMA (comparing it to the hardware coherency requirements), so that > alignment at allocation time simply wouldn't matter. > > At that point, places like the ones you found would still work, they'd > just cause bouncing. > > At which point you'd then have a choice of > > (a) just let it bounce > > (b) marking the allocations that led to them > > and (a) might actually be perfectly fine in a lot of situations. Non-coherent DMA for networking is going to be fun, though. Fortunately, we'll only need to bounce for inbound DMA (where the cache invalidation might otherwise corrupt adjacent unrelated data), and for inbound networking, the driver typically owns and maps the buffers, and so in most cases, it can hopefully be easily modified to round up the allocations and the length values passed to dma_map_xxx(). And for outbound, we can just clean the SKB from the caches without the risk of corruption. It does mean that there is likely going to be a long tail of network drivers that will non-negligibly regress in performance and in memory footprint (as the entire RX ring will be double buffered all the time) until they get updated. -- Ard.
