On Fri, Feb 1, 2019 at 1:06 PM Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > > On Fri, Feb 01, 2019 at 09:22:26AM -0800, Peter Oskolkov wrote: > > This patch implements BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap > > BPF helper. It enables BPF programs (specifically, BPF_PROG_TYPE_LWT_IN > > and BPF_PROG_TYPE_LWT_XMIT prog types) to add IP encapsulation headers > > to packets (e.g. IP/GRE, GUE, IPIP). > > > > This is useful when thousands of different short-lived flows should be > > encapped, each with different and dynamically determined destination. > > Although lwtunnels can be used in some of these scenarios, the ability > > to dynamically generate encap headers adds more flexibility, e.g. > > when routing depends on the state of the host (reflected in global bpf > > maps). > > > > Note: a follow-up patch with deal with GSO-enabled packets, which > > are currently rejected at encapping attempt. > > > > Signed-off-by: Peter Oskolkov <p...@google.com> > ... > > +int bpf_lwt_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len, bool > > ingress) > > +{ > > + struct iphdr *iph; > > + bool ipv4; > > + int err; > > + > > + if (unlikely(len < sizeof(struct iphdr) || len > > > LWT_BPF_MAX_HEADROOM)) > > + return -EINVAL; > > + > > + /* GSO-enabled packets cannot be encapped at the moment. */ > > + if (unlikely(skb_is_gso(skb))) > > + return -EINVAL; > > I don't understand why that's 'unlikely'. > Both tx and rx are very likely to have gso skbs. > Are you saying this feature will require user to disable gro/gso on a device? > imo gso has to be supported from the start.
OK, I'll work on v7 with GSO support... :) >