Re: [PATCH v1 3/3] net/af_packet: software checksum and tx poll control

Scott Mitchell
2026-01-28T18:59:29Z

> Well tap should NOT be doing software GSO and LRO in DPDK.
> The kernel driver has ability to do that, and is better done there.

Agreed if we can propagate context to the other end of the device best
to let it handle it. Some context/constraints:
- current mechanism to propagate context to kernel (virtio_net_hdr)
doesn't support propagating "please do ipv4 checksum for me", and is
done in software for virtio too [1]
- I have a not-yet-submitted patch to add virtio_net_hdr support to
af_packet PMD (for TSO/LRO). When enabled, the kernel requires every
packet rx/tx has the virtio_net_hdr header, and I currently made this
opt-in as a vdev arg.

This leaves some options:
1. cksum support independent from virtio_net_hdr (my current approach)
If virtio_net_hdr is enabled and supported - use it. If not, the
software fallback path provides cksum (what is in this patch)
- Pros - cksum is supported regardless of virtio_net_hdr
support/errors, overhead of virtio_net_hdr not required for cksum
- Cons - 2 paths for checksum, more code (even if shared with TAP)

2. cksum support ONLY IF virtio_net_hdr enabled/supported
Pros - Single code path for checksum, L4 cksum "offloaded" (L3 still
done in software)
Cons - must always enable virtio_net_hdr to get cksum/TSO/LRO,
overhead of virtio_net_hdr on each packet

Do you prefer option (2)? fwiw, I didn't observe meaningful overhead
from virtio_net_hdr, and it seems viable.

[1] https://github.com/DPDK/dpdk/blob/v25.11/lib/vhost/virtio_net.c#L690-L697