On Thursday, July 3, 2025 11:58 PM, Daniel Borkmann daniel@iogearbox.net wrote:
On 7/2/25 6:57 PM, Song Yoong Siang wrote: [...]
+It is important to note that some devices may utilize the ``data_meta`` area for +their own purposes. For example, the IGC device utilizes ``IGC_TS_HDR_LEN`` +bytes of the ``data_meta`` area for receiving hardware timestamps. Therefore, +the XDP program should ensure that it does not overwrite any existing metadata. +The metadata layout of such device is depicted below::
- +----------+-----------------+--------------------------+------+
- | headroom | custom metadata | device-reserved metadata | data |
- +----------+-----------------+--------------------------+------+
^ ^| |- xdp_buff->data_meta xdp_buff->data
Imho, this section is misleading to developers. Suppose you're a XDP program writer and you want to implement a generic native BPF program (independent of the underlying NIC). Does this mean, the expectation is to dig into driver code to gather whether or not a driver is prepopulating and how much of it? What are the implications if the data is overwritten? For example, in Cilium today we use the buffer described here as device-reserved metadata and override it. How will users know what breaks?
Thanks for your input.
A generic XDP program can always check the size of device-reserved metadata by "ctx->data - ctx->data_meta" and avoid overwrite it, as shown in code below in my v1 submission [1]. This requires driver to expose the metadata length used [2]. However, I dint have good justification for making the metadata length user-visible. So, I submitted this v3 to keep it simple. Any thoughts?
+ metalen_used = ctx->data - ctx->data_meta; + metalen_to_adjust = XDP_METADATA_SIZE - metalen_used; + if (metalen_to_adjust < (int)sizeof(struct xdp_meta)) + return XDP_DROP; + + ret = bpf_xdp_adjust_meta(ctx, -metalen_to_adjust);
[1] https://lore.kernel.org/netdev/20250701042940.3272325-3-yoong.siang.song@int... [2] https://lore.kernel.org/netdev/20250701080955.3273137-1-yoong.siang.song@int...