On Tue, Jan 29, 2019 at 7:29 PM David Ahern <dsah...@gmail.com> wrote:
>
> On 1/28/19 6:12 PM, Peter Oskolkov wrote
> > @@ -2583,7 +2594,15 @@ enum bpf_ret_code {
> > BPF_DROP = 2,
> > /* 3-6 reserved */
> > BPF_REDIRECT = 7,
> > - /* >127 are reserved for prog type specific return codes */
> > + /* >127 are reserved for prog type specific return codes.
> > + *
> > + * BPF_LWT_REROUTE: used by BPF_PROG_TYPE_LWT_IN and
> > + * BPF_PROG_TYPE_LWT_XMIT to indicate that skb's dst
> > + * has changed and appropriate dst_input() or dst_output()
> > + * action has to be taken (this is an L3 redirect, as
> > + * opposed to L2 redirect represented by BPF_REDIRECT above).
> > + */
> > + BPF_LWT_REROUTE = 128,
> > };
>
> What happens if a program pushes a new header onto the skb and does not
> return BPF_LWT_REROUTE?
>
> Might be better to move the route lookup and dst swap to run_lwt_bpf and
> only do it if the program returns BPF_LWT_REROUTE. That allows calling
> bpf_push_ip_encap without requiring a route lookup. That might be fine
> as long as their is not a protocol mismatch (ipv4 packet gets an ipv6
> header or vice versa). But then, I think you have the mismatch problem
> now if the program does not return BPF_LWT_REROUTE.
Makes sense - thanks for the suggestion I'll send a v4 later today.
Thanks,
Peter
