On Thu, Apr 24, 2025 at 08:39 AM -07, Stanislav Fomichev wrote: > On 04/24, Toke Høiland-Jørgensen wrote: [...] >> Being able to change the placement (and format) of the data store is the >> reason why we should absolutely *not* expose the internal trait storage >> to AF_XDP. Once we do that, we effectively make the whole thing UAPI. >> The trait get/set API very deliberately does not expose any details >> about the underlying storage for exactly this reason :) > > I was under the impression that we want to eventually expose trait > blobs to the userspace via getsockopt (or some other similar means), > is it not the case? How is userspace supposed to consume it? Yes, we definitely want to consume and produce traits from userspace. Before last Netdev [1], our plan was for the socket glue layer to convert between the in-kernel format and a TLV-based stable format for uAPI. But then Alexei suggested something that did not occur to us. The traits format can be something that BPF and userspace agree on. The kernel just passes it back and forth without needing to understand the content. This naturally simplifies changes in the socket glue layer. As Eric pointed out, this is similar to exposing raw TCP SYN headers via getsockopt(TCP_SAVED_SYN). BPF can set a custom TCP option, and userspace can consume it. The trade-off is that then the traits can only be used in parts of the network stack where a BPF hook exist. Is that an acceptable limitation? That's what we're hoping to hear your thoughts on. One concern that comes to mind, since the network stack is unaware of traits contents, we will be limited to simple merge strategies (like "drop all" or "keep first") in the GRO layer. [1] https://www.netdevconf.info/0x19/sessions/talk/traits-rich-packet-metadata.html
