On Thu, 17 Sep 2020 at 13:55, Maciej Żenczykowski <m...@google.com> wrote: > > > (b) another complexity with bpf_redirect() is you can call it, it can succeed, > but then you can not return TC_ACT_REDIRECT from the bpf program, > which effectively makes the earlier *successful* bpf_redirect() call > an utter no-op. > > (bpf_redirect() just determines what a future return TC_ACT_REDIRECT will do) > > so if you bpf_redirect to interface with larger mtu, then increase packet > size, > then return TC_ACT_OK, then you potentially end up with excessively large > packet egressing through original interface (with small mtu).
Yeah, this isn't nice. What is the use case for allowing this in the first place? For sk_lookup programs, we have a similar situation, except that we "redirect" to a socket. Here the redirect happens if the helper call is successful and the program returns SK_PASS. Maybe that is a feasible approach if we introduce new helpers. -- Lorenz Bauer | Systems Engineer 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK www.cloudflare.com
