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). 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 :)
