Just a separate comment on this bit: John Fastabend <john.fastabend@xxxxxxxxx> writes: > If you go with in-kernel BPF kfunc approach (vs user space side) I think > you also need to add CO-RE to be friendly for driver developers? Otherwise > they have to keep that read in sync with the descriptors? CO-RE is for doing relocations of field offsets without having to recompile. That's not really relevant for the kernel, that gets recompiled whenever the layout changes. So the field offsets are just kept in sync with offsetof(), like in Stanislav's RFCv2 where he had this snippet: + /* return ((struct sk_buff *)r5)->tstamp; */ + BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_5, + offsetof(struct sk_buff, tstamp)), So I definitely don't think this is an argument against the kfunc approach? > Also need to handle versioning of descriptors where depending on > specific options and firmware and chip being enabled the descriptor > might be moving around. This is exactly the kind of thing the driver is supposed to take care of; it knows the hardware configuration and can pick the right descriptor format. Either by just picking an entirely different kfunc unroll depending on the config (if it's static), or by adding the right checks to the unroll. You'd have to replicate all this logic in BPF anyway, and while I'm not doubting *you* are capable of doing this, I don't think we should be forcing every XDP developer to deal with all this. Or to put it another way, a proper hardware abstraction and high-quality drivers is one of the main selling points of XDP over DPDK and other kernel bypass solutions; we should not jettison this when enabling metadata support! -Toke
