On Thu, 4 Aug 2022 14:55:14 -0700 Joanne Koong wrote: > Thinking about this some more, I don't think we get a lot of benefits > from combining it into one API (bpf_dynptr_from_packet) instead of 2 > separate APIs (bpf_dynptr_from_skb / bpf_dynptr_from_xdp). Ease of use is not a big benefit? We'll continue to have people trying to run XDP generic in prod because they wrote their program for XDP, not tc :( > The bpf_dynptr_write behavior will be inconsistent (eg bpf_dynptr_write > into xdp frags will work whereas bpf_dynptr_write into skb frags will > fail). Martin also pointed out that he'd prefer bpf_dynptr_write() to > succeed for writing into frags and invalidate data slices (instead of > failing the write and always keeping data slices valid), which we > can't do if we combine xdp + skb, without always (needlessly) > invalidating xdp data slices whenever there's a write. Additionally, > in the verifier, there's no organic mapping between prog type -> prog > ctx, so we'll have to hardcode some mapping between prog type -> skb > vs. xdp ctx. I think for these reasons it makes more sense to have 2 > separate APIs, instead of having 1 API that both hooks can call. Feels like pushing complexity onto users because the infra is not in place. One day the infra will be in place yet the uAPI will remain for ever. But enough emails exchanged, take your pick and time will tell :)
