From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roopa Prabhu Subject: Re: [PATCH net-next v2 3/5] bpf: BPF for lightweight tunnel encapsulation Date: Wed, 02 Nov 2016 06:39:13 -0700 Message-ID: <5819EC81.90405@cumulusnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: davem@davemloft.net, alexei.starovoitov@gmail.com, daniel@iogearbox.net, tom@herbertland.com, netdev@vger.kernel.org To: Thomas Graf Return-path: Received: from mail-pf0-f180.google.com ([209.85.192.180]:33401 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752971AbcKBNjQ (ORCPT ); Wed, 2 Nov 2016 09:39:16 -0400 Received: by mail-pf0-f180.google.com with SMTP id d2so12517849pfd.0 for ; Wed, 02 Nov 2016 06:39:16 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On 10/31/16, 5:37 PM, Thomas Graf wrote: > Register two new BPF prog types BPF_PROG_TYPE_LWT_IN and > BPF_PROG_TYPE_LWT_OUT which are invoked if a route contains a > LWT redirection of type LWTUNNEL_ENCAP_BPF. > > The separate program types are required because manipulation of > packet data is only allowed on the output and transmit path as > the subsequent dst_input() call path assumes an IP header > validated by ip_rcv(). The BPF programs will be handed an skb > with the L3 header attached and may return one of the following > return codes: > > BPF_OK - Continue routing as per nexthop > BPF_DROP - Drop skb and return EPERM > BPF_REDIRECT - Redirect skb to device as per redirect() helper. > (Only valid on lwtunnel_xmit() hook) > > The return codes are binary compatible with their TC_ACT_ > relatives to ease compatibility. > > A new helper bpf_skb_push() is added which allows to preprend an > L2 header in front of the skb, extend the existing L3 header, or > both. This allows to address a wide range of issues: > - Optimize L2 header construction when L2 information is always > static to avoid ARP/NDisc lookup. > - Extend IP header to add additional IP options. > - Perform simple encapsulation where offload is of no concern. > (The existing funtionality to attach a tunnel key to the skb > and redirect to a tunnel net_device to allow for offload > continues to work obviously). > > Signed-off-by: Thomas Graf > --- > [snip] > diff --git a/net/Kconfig b/net/Kconfig > index 7b6cd34..7554f12 100644 > --- a/net/Kconfig > +++ b/net/Kconfig > @@ -396,6 +396,7 @@ source "net/nfc/Kconfig" > > config LWTUNNEL > bool "Network light weight tunnels" > + depends on IPV6 || IPV6=n > ---help--- > This feature provides an infrastructure to support light weight > tunnels like mpls. There is no netdevice associated with a light > diff --git a/net/core/Makefile b/net/core/Makefile > index d6508c2..a675fd3 100644 > --- a/net/core/Makefile > +++ b/net/core/Makefile > @@ -23,7 +23,7 @@ obj-$(CONFIG_NETWORK_PHY_TIMESTAMPING) += timestamping.o > obj-$(CONFIG_NET_PTP_CLASSIFY) += ptp_classifier.o > obj-$(CONFIG_CGROUP_NET_PRIO) += netprio_cgroup.o > obj-$(CONFIG_CGROUP_NET_CLASSID) += netclassid_cgroup.o > -obj-$(CONFIG_LWTUNNEL) += lwtunnel.o > +obj-$(CONFIG_LWTUNNEL) += lwtunnel.o lwt_bpf.o Any reason you want to keep lwt bpf under the main CONFIG_LWTUNNEL infra config ?. since it is defined as yet another plug-gable encap function, seems like it will be better under a separate CONFIG_LWTUNNEL_BPF or CONFIG_LWT_BPF that depends on CONFIG_LWTUNNEL