On Thursday, July 3, 2025 11:58 PM, Daniel Borkmann <daniel@xxxxxxxxxxxxx> 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@xxxxxxxxx/ [2] https://lore.kernel.org/netdev/20250701080955.3273137-1-yoong.siang.song@xxxxxxxxx/