From: Roopa Prabhu <roopa@cumulusnetworks•com>
To: Thomas Graf <tgraf@suug•ch>
Cc: davem@davemloft•net, alexei.starovoitov@gmail•com,
daniel@iogearbox•net, tom@herbertland•com,
netdev@vger•kernel.org
Subject: Re: [PATCH net-next v2 3/5] bpf: BPF for lightweight tunnel encapsulation
Date: Wed, 02 Nov 2016 06:39:13 -0700 [thread overview]
Message-ID: <5819EC81.90405@cumulusnetworks.com> (raw)
In-Reply-To: <d8c7e07ac7d289a2846af8d659287f3512a4edec.1477959702.git.tgraf@suug.ch>
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 <tgraf@suug•ch>
> ---
>
[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
next prev parent reply other threads:[~2016-11-02 13:39 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-01 0:37 [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation Thomas Graf
2016-11-01 0:37 ` [PATCH net-next v2 1/5] route: Set orig_output when redirecting to lwt on locally generated traffic Thomas Graf
2016-11-01 0:37 ` [PATCH net-next v2 2/5] route: Set lwtstate for local traffic and cached input dsts Thomas Graf
2016-11-01 0:37 ` [PATCH net-next v2 3/5] bpf: BPF for lightweight tunnel encapsulation Thomas Graf
2016-11-01 1:10 ` kbuild test robot
2016-11-01 2:39 ` kbuild test robot
2016-11-01 20:11 ` David Ahern
2016-11-01 21:03 ` Thomas Graf
2016-11-02 13:39 ` Roopa Prabhu [this message]
2016-11-02 22:58 ` Thomas Graf
2016-11-01 0:37 ` [PATCH net-next v2 4/5] bpf: Add samples for LWT-BPF Thomas Graf
2016-11-01 0:37 ` [PATCH net-next v2 5/5] lwtunnel: Limit number of recursions on output to 5 Thomas Graf
2016-11-01 4:52 ` kbuild test robot
2016-11-01 8:09 ` Thomas Graf
2016-11-01 10:54 ` [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation Hannes Frederic Sowa
2016-11-01 18:51 ` Thomas Graf
2016-11-01 20:08 ` Hannes Frederic Sowa
2016-11-01 20:59 ` Thomas Graf
2016-11-01 22:12 ` Hannes Frederic Sowa
2016-11-01 23:07 ` Tom Herbert
2016-11-02 10:48 ` Hannes Frederic Sowa
2016-11-02 16:59 ` Tom Herbert
2016-11-03 14:16 ` Thomas Graf
2016-11-02 22:57 ` Thomas Graf
2016-11-02 23:27 ` Tom Herbert
2016-11-02 22:54 ` Thomas Graf
2016-11-03 14:52 ` Hannes Frederic Sowa
2016-11-03 15:20 ` Thomas Graf
2016-11-01 16:17 ` Tom Herbert
2016-11-01 18:20 ` Thomas Graf
2016-11-01 18:51 ` Tom Herbert
2016-11-01 19:11 ` Thomas Graf
2016-11-01 19:27 ` Tom Herbert
2016-11-01 19:59 ` Thomas Graf
2016-11-01 20:33 ` Tom Herbert
2016-11-01 21:05 ` Thomas Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5819EC81.90405@cumulusnetworks.com \
--to=roopa@cumulusnetworks$(echo .)com \
--cc=alexei.starovoitov@gmail$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=tgraf@suug$(echo .)ch \
--cc=tom@herbertland$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox