Re: [PATCH bpf-next v6 2/5] bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap
From: Alexei Starovoitov <hidden>
Date: 2019-02-01 21:06:48
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 <redacted>
...
+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.