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.

Reply via email to