> 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
