Thread (8 messages) 8 messages, 3 authors, 2019-02-01

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help