Hi Stephen, > I wonder if TPACKET header could go in mbuf headroom. > And also, could the copy on receive be avoided?
Thank you for your review and the interesting questions. I had not considered these angles, so I took some time to look into it. As far as I understand, the current RX path copies the packet data from the ring frame into an mbuf so that the ring slot can be returned to the kernel immediately after the copy. This keeps the ring available for new packets regardless of how long the application holds the mbuf. Going down the zero-copy route would introduce a strong coupling between kernel-managed ring frames and DPDK-managed mbufs: the ring slot could not be released until the last reference to the mbuf is freed, which risks stalling the ring under any buffering. Because of this copy and the resulting decoupling, the TPACKET header does not need to be carried into the mbuf at all. It is only read for metadata (packet length, VLAN, timestamp) before the frame is released back to the kernel. In this context, my feeling is that the introduced risks outweigh the gains (the memcpy looks relatively small compared to the full kernel networking stack af_packet goes through). Did I miss something? Regards, Xavier
