Jakub Kicinski wrote: > On Thu, 05 Jun 2025 20:09:55 -0400 Willem de Bruijn wrote: > > > > It does make a fair bit of sense. > > > > Question: does calling it as a kfunc require kernel BTF? > > > > Specifically some ram limited devices want to disable CONFIG_DEBUG_INFO_BTF... > > > > I know normal bpf helpers don't need that... > > > > I guess you could always convert ipv4 -> ipv6 -> ipv4 ;-) > > > > > > Not sure how BPF folks feel about that, but technically we could > > > also add a flag to bpf_skb_adjust_room() or bpf_skb_change_proto(). > > > > To invert the question: what is the value in keeping the dst? > > I guess simplicity defined as "how many English words are needed to > explain the semantics". > > The semantics I have in mind would be - dst is dropped if (1) proto > is changed (this patch), or (2) "CLEAR_DST" flag is explicitly set > (future extension). > > If we drop on encap (which I supposed is the counter proposal) > we may end up with: dst is dropped if (1) proto is changed, > (2) encap flags are set (1+2 = alternative patch), or (3) "CLEAR_DST" > flag is explicitly set (future extension). I was just wondering what the effect is of dropping, and why we should err on the side of minimizing that. Leaving it to the authors of a BPF program to understand whether they should call a kfunc seems dangerous and error prone. I would drop on every program that calls bpf_skb_adjust_room() or bpf_skb_change_proto(). This patch LGTM in other words. If anything, I would drop more aggressively. > Don't think we can rule out the need for a CLEAR_DST flag as not all > re-routings are encaps. > > But both you and Maciej consider dropping for all encaps more > intuitive, so I'll do that in v2 unless someone objects. > > > The test refers to a nat6to4.bpf.o, but this is not included. > > I reused an existing BPF prog, it does what we need - > it turns a v4 packet into a v6 one :) Oops yes, thanks. I somehow missed that in my quick `find`.
