From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: David Ahern <dsahern@gmail.com>
Cc: Peter Oskolkov <posk@google.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, Peter Oskolkov <posk@posk.io>,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH bpf-next v11 0/7] bpf: add BPF_LWT_ENCAP_IP option to bpf_lwt_push_encap
Date: Wed, 13 Feb 2019 20:21:29 -0800 [thread overview]
Message-ID: <20190214042127.azcsxbrpzhgumiwa@ast-mbp> (raw)
In-Reply-To: <3772c82a-6959-9f8a-9273-0adcbdbcf631@gmail.com>
On Wed, Feb 13, 2019 at 08:44:51PM -0700, David Ahern wrote:
> On 2/13/19 7:39 PM, Alexei Starovoitov wrote:
> > On Wed, Feb 13, 2019 at 05:46:26PM -0700, David Ahern wrote:
> >> On 2/13/19 12:53 PM, Peter Oskolkov wrote:
> >>> This patchset 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).
> >>>
> >>
> >>
> >> For the set:
> >> Reviewed-by: David Ahern <dsahern@gmail.com>
> >
> > Applied. Thanks everyone!
> >
>
> Looks like a cleanup round is needed.
>
> I changed the routes to fail with unreachable:
>
> @@ -179,16 +175,16 @@
> ip -netns ${NS3} tunnel add gre_dev mode gre remote ${IPv4_1} local
> ${IPv4_GRE} ttl 255
> ip -netns ${NS3} link set gre_dev up
> ip -netns ${NS3} addr add ${IPv4_GRE} dev gre_dev
> - ip -netns ${NS1} route add ${IPv4_GRE}/32 dev veth5 via ${IPv4_6}
> - ip -netns ${NS2} route add ${IPv4_GRE}/32 dev veth7 via ${IPv4_8}
> + ip -netns ${NS1} route add unreachable ${IPv4_GRE}/32
> + ip -netns ${NS2} route add unreachable ${IPv4_GRE}/32
>
>
> # configure IPv6 GRE device in NS3, and a route to it via the "bottom"
> route
> ip -netns ${NS3} -6 tunnel add name gre6_dev mode ip6gre remote
> ${IPv6_1} local ${IPv6_GRE} ttl 255
> ip -netns ${NS3} link set gre6_dev up
> ip -netns ${NS3} -6 addr add ${IPv6_GRE} nodad dev gre6_dev
> - ip -netns ${NS1} -6 route add ${IPv6_GRE}/128 dev veth5 via ${IPv6_6}
> - ip -netns ${NS2} -6 route add ${IPv6_GRE}/128 dev veth7 via ${IPv6_8}
> + ip -netns ${NS1} -6 route add unreachable ${IPv6_GRE}/128
> + ip -netns ${NS2} -6 route add unreachable ${IPv6_GRE}/128
>
> # rp_filter gets confused by what these tests are doing, so disable it
> ip netns exec ${NS1} sysctl -wq net.ipv4.conf.all.rp_filter=0
> @@ -220,7 +216,6 @@
>
>
> and then removed all of the set -e and exit 1's in the script (really
> should let all of the tests run versus bailing on the first failure).
>
> With kmemleak enabled I see a lot of suspected memory leaks - some may
> not be related to this change but it is triggering the suspected leak:
argh. Thanks a lot for catching it.
Let's figure out the fix quickly.
If it's too intrusive we can revert and reapply.
I'm not going to send a pull-req to Dave with a known issue like this.
next prev parent reply other threads:[~2019-02-14 4:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 19:53 [PATCH bpf-next v11 0/7] bpf: add BPF_LWT_ENCAP_IP option to bpf_lwt_push_encap Peter Oskolkov
2019-02-13 19:53 ` [PATCH bpf-next v11 1/7] bpf: add plumbing for BPF_LWT_ENCAP_IP in bpf_lwt_push_encap Peter Oskolkov
2019-02-13 19:53 ` [PATCH bpf-next v11 2/7] bpf: implement BPF_LWT_ENCAP_IP mode " Peter Oskolkov
2019-02-13 19:53 ` [PATCH bpf-next v11 3/7] bpf: handle GSO " Peter Oskolkov
2019-02-13 19:53 ` [PATCH bpf-next v11 4/7] ipv6_stub: add ipv6_route_input stub/proxy Peter Oskolkov
2019-02-13 19:53 ` [PATCH bpf-next v11 5/7] bpf: add handling of BPF_LWT_REROUTE to lwt_bpf.c Peter Oskolkov
2019-02-13 19:53 ` [PATCH bpf-next v11 6/7] bpf: sync <kdir>/include/.../bpf.h with tools/include/.../bpf.h Peter Oskolkov
2019-02-13 19:53 ` [PATCH bpf-next v11 7/7] selftests: bpf: add test_lwt_ip_encap selftest Peter Oskolkov
2019-02-14 6:03 ` Stanislav Fomichev
2019-02-14 0:46 ` [PATCH bpf-next v11 0/7] bpf: add BPF_LWT_ENCAP_IP option to bpf_lwt_push_encap David Ahern
2019-02-14 2:39 ` Alexei Starovoitov
2019-02-14 3:44 ` David Ahern
2019-02-14 4:21 ` Alexei Starovoitov [this message]
2019-02-14 5:36 ` Peter Oskolkov
2019-02-14 6:11 ` Peter Oskolkov
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=20190214042127.azcsxbrpzhgumiwa@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=dsahern@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=posk@google.com \
--cc=posk@posk.io \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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