In AF_PACKET, the PMD reads the timestamp from socket ring headers because the kernel stack processes the packet and allocates a socket buffer. Since the kernel stack and socket buffer allocation are bypassed in AF_XDP, UMEM frames are given directly to the PMD, which means the kernel never generates these socket headers. Also, it looks like the TAP PMD doesn't support RX timestamps.
Since the location of metadata in the UMEM headroom is determined by the XDP program, the current driver implementation is coupled to a specific XDP program layout. As an alternative, we could just plumb the entire metadata headroom to the DPDK application and let the application parse it based on whatever XDP program is in use. That would couple the application and the XDP program, but would at least decouple the driver and the XDP program. On Tue, Jun 23, 2026 at 3:06 PM Stephen Hemminger <[email protected]> wrote: > > On Tue, 23 Jun 2026 21:53:24 +0000 > Mark Blasko <[email protected]> wrote: > > > + if (rxq->rx_timestamp_enabled && > > + timestamp_dynfield_offset >= 0) { > > + struct af_xdp_rx_metadata *meta; > > + > > + meta = (struct af_xdp_rx_metadata *) > > + ((char *)rte_pktmbuf_mtod(bufs[i], void *) - > > + sizeof(struct af_xdp_rx_metadata)); > > + *RTE_MBUF_DYNFIELD(bufs[i], > > + timestamp_dynfield_offset, > > + uint64_t *) = meta->rx_timestamp; > > + bufs[i]->ol_flags |= timestamp_dynflag; > > + } > > + > > Why does XDP time stamp need to be different than how other drivers > already do timestamps. See AF_PACKET and TAP device? > > Should not be driver specific here.
