Re: mlx5e:zero-prefix corruption during TCP DMA-BUF RX - help requested

[Dragos Tatulea <dtatulea@nvidia.com>]

Hi Jiabin,

On 15.09.26 03:49, jiabin deng wrote:
> Hello mlx5e and networking maintainers,
> 
> We are investigating reproducible data corruption: with SHAMPO enabled,
> some TCP data is corrupted when received through mlx5e directly into
> CUDA-exported GPU DMA-BUF memory.
> 
> The full expected number of bytes is received, but the prefixes of some
> payloads become zero. The corrupted ranges end exactly at the next
> 64-byte boundary in GPU memory.
>> [...]
>
> Each iteration uses a new TCP connection. Test connections do not run
> concurrently.
> 
> Observed results:
> 
> We tested eight message sizes from 32 KiB to 4 MiB, with 50 iterations
> per size:
> 
> - 400 iterations completed.
> - 354 iterations contained at least one corrupted range.
> - 20,707 corrupted ranges were recorded.
> - All recorded corrupted ranges were zero-filled prefixes ending
>   at the next 64-byte boundary in GPU memory.
> - Corruption was present in both snapshots, before and after the
>   explicit GPUDirect write flush.
> 
> A specific example:
> 
> - Packet payload length: 1448 bytes.
> - Offset of the first payload byte from the start of the GPU buffer:
>   2149169912 bytes.
> - This byte offset modulo 64 bytes is 56 bytes.
> - First 8 bytes: zero.
> - Remaining 1440 bytes: correct.
> 
This sounds a bit like the ethernet padding issue that was recently
fixed [1]. Did you have this patch when testing?

>
> [...]
>

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=e2466392a0b8496000e12181cb1ee1535eb0da25

Thanks,
Dragos