Re: [PATCH] swiotlb: avoid double copy with swiotlb on tx socket

On 24.08.26 17:32, Luigi Rizzo wrote:

On Mon, Aug 24, 2026 at 10:59 AM Dragos Tatulea [off-list ref] wrote:

quoted

...

quoted

An example of this is Jiri's system_cc_shared heap which is a dma-buf
heap with decrypted memory for userspace.

quoted

I am still looking into this, I was planning to bring this up in the
upcoming LPC.
I will give this patch a try. However, I believe that we need a more
generalised concept for CoCo pre-decrypted allocators in the kernel.

There is a talk at LPC in the networking track about this [2]. This is
exactly the type of discussion that I was hoping to have there.

Besides the issues mentioned in this thread we've also found that a lot
of overhead can come only from swiotlb allocations when running many queues.

I will add information about this series in my talk. Hopefully I will also
have time to add some numbers for comparison.

Sorry for the late reply but I spotted this thread only now by
accident.

[1] https://lore.kernel.org/all/20260325192352.437608-3-jiri@resnulli.us/ (local)
[2] https://lpc.events/event/20/contributions/2464

Thank you for the feedback and links.

Do you have some code describing [2] ?

Not yet I will send a link once I push it somewhere. But the idea is simple:
a driver side alternative data-path which uses pre-allocated coherent DMA buffers.
This doesn't make memcpy go away but eliminates the swiotlb all together and it
reduces the DMA map/unmap overhead.

I just sent a cleaned-up v2 of my previous series, if you want to try
it please use the latter.

Thanks! Had a quick lock and wrote some comments.

Thanks,
Dragos