[RFC] virtio-net: AF_XDP zero-copy TX checksum offload

[RFC] virtio-net: AF_XDP zero-copy TX checksum offload

[Azadeh Aftahi]

Hi all,

I'm planning to work on single-buffer AF_XDP zero-copy TX checksum offload for virtio-net.

Current net-next's virtnet_xsk_xmit_one() does not consume XSK TX checksum metadata and uses the shared zeroed virtio header.

I found Xuan's 2021 proposal anticipating separate headers for checksum support, and the merged 2024 zero-copy TX series, 
but I couldn't find a checksum-specific follow-up implementation.

The proposed scope is to map the existing XSK checksum metadata API to VIRTIO_NET_F_CSUM, 
using a DMA-safe per-packet virtio header whose lifetime extends until TX completion, with corresponding completion, reset, and unbind cleanup.

I would keep the initial scope limited to single-buffer TX: no multi-buffer RX, timestamps, launch time, or GSO.

I'd also add checksum and header-lifetime coverage using the existing XSK selftest framework with QEMU/TAP.

Is anyone already working on this? If not, does this scope and per-packet-header approach sound reasonable for a follow-up patch?

Thanks,
Azadeh

Re: [RFC] virtio-net: AF_XDP zero-copy TX checksum offload

[Xuan Zhuo]

On Mon, 5 Oct 2026 17:28:35 -0500, Azadeh Aftahi <aftahi334@gmail.com> wrote:
> Hi all,
>
> I'm planning to work on single-buffer AF_XDP zero-copy TX checksum offload for virtio-net.
>
> Current net-next's virtnet_xsk_xmit_one() does not consume XSK TX checksum metadata and uses the shared zeroed virtio header.
>
> I found Xuan's 2021 proposal anticipating separate headers for checksum support, and the merged 2024 zero-copy TX series, but I couldn't find a checksum-specific follow-up implementation.
>
> The proposed scope is to map the existing XSK checksum metadata API to VIRTIO_NET_F_CSUM, using a DMA-safe per-packet virtio header whose lifetime extends until TX completion, with corresponding completion, reset, and unbind cleanup.
>
> I would keep the initial scope limited to single-buffer TX: no multi-buffer RX, timestamps, launch time, or GSO.
>
> I'd also add checksum and header-lifetime coverage using the existing XSK selftest framework with QEMU/TAP.
>
> Is anyone already working on this? If not, does this scope and per-packet-header approach sound reasonable for a follow-up patch?

It seems no one has taken this work forward yet; I would welcome it if you were
to do so.

Thanks.


>
> Thanks,
> Azadeh

Re: [RFC] virtio-net: AF_XDP zero-copy TX checksum offload

[Azadeh Aftahi]

Hi Xuan,

Thank you for the response and encouragement.
I'll proceed with the single-buffer AF_XDP zero-copy TX checksum offload work and share an RFC patch for review once the initial implementation and tests are ready.

Thanks,
Azadeh

> On Oct 7, 2026, at 8:35 PM, Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
> 
> On Mon, 5 Oct 2026 17:28:35 -0500, Azadeh Aftahi <aftahi334@gmail.com> wrote:
>> Hi all,
>> 
>> I'm planning to work on single-buffer AF_XDP zero-copy TX checksum offload for virtio-net.
>> 
>> Current net-next's virtnet_xsk_xmit_one() does not consume XSK TX checksum metadata and uses the shared zeroed virtio header.
>> 
>> I found Xuan's 2021 proposal anticipating separate headers for checksum support, and the merged 2024 zero-copy TX series, but I couldn't find a checksum-specific follow-up implementation.
>> 
>> The proposed scope is to map the existing XSK checksum metadata API to VIRTIO_NET_F_CSUM, using a DMA-safe per-packet virtio header whose lifetime extends until TX completion, with corresponding completion, reset, and unbind cleanup.
>> 
>> I would keep the initial scope limited to single-buffer TX: no multi-buffer RX, timestamps, launch time, or GSO.
>> 
>> I'd also add checksum and header-lifetime coverage using the existing XSK selftest framework with QEMU/TAP.
>> 
>> Is anyone already working on this? If not, does this scope and per-packet-header approach sound reasonable for a follow-up patch?
> 
> It seems no one has taken this work forward yet; I would welcome it if you were
> to do so.
> 
> Thanks.
> 
> 
>> 
>> Thanks,
>> Azadeh