Re: [PATCH net] net: clear the dst when changing skb protocol

[Jakub Kicinski <kuba@kernel.org>]

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