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

[Dragos Tatulea]

On 25.08.26 18:33, Mostafa Saleh wrote:
> On Mon, Aug 24, 2026 at 10:59:21AM +0200, Dragos Tatulea wrote:
>>
>>
>> On 16.06.26 13:06, Mostafa Saleh wrote:
>>> On Tue, Jun 16, 2026 at 02:33:52AM +0200, Luigi Rizzo wrote:
>>> [...]
>>> 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.
> 
> I see, thanks for point that. I plan to be in LPC, so I will aim to
> attend this talk.
> 
Great!

>>
>> 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.
> 
> I had a quick look, I am not sure how that will shape at the end, but I
> think we need a general solution beyond NICs. For example in pKVM the
> bouncing is used with virtio devices, so doing this per-driver won't
> really work and is not possible in some scenarios where memory is
> allocated from the core kernel and then passed to the driver.
> So, I was thinking the kernel relying on
> CC_ATTR_MEM_ENCRYPT/force_dma_unencrypted() could detect that and
> allocate pre-shared memory for those cases.
>
Ideally it shouldn't be per driver. But I was thinking that there should
be a way for the user to provision memory for certain devices.

Thanks,
Dragos