| Message ID | 20201103042908.2825734-2-liuhangbin@gmail.com |
|---|---|
| State | Not Applicable |
| Delegated to: | BPF Maintainers |
| Headers | show |
| Series | selftest/bpf: improve bpf tunnel test | expand |
| Context | Check | Description |
|---|---|---|
| jkicinski/cover_letter | success | Link |
| jkicinski/fixes_present | success | Link |
| jkicinski/patch_count | success | Link |
| jkicinski/tree_selection | success | Clearly marked for bpf-next |
| jkicinski/subject_prefix | success | Link |
| jkicinski/source_inline | success | Was 0 now: 0 |
| jkicinski/verify_signedoff | success | Link |
| jkicinski/module_param | success | Was 0 now: 0 |
| jkicinski/build_32bit | fail | Errors and warnings before: 4 this patch: 4 |
| jkicinski/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| jkicinski/verify_fixes | success | Link |
| jkicinski/checkpatch | fail | Link |
| jkicinski/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
| jkicinski/header_inline | success | Link |
| jkicinski/stable | success | Stable not CCed |
On Tue, Nov 03, 2020 at 12:29:07PM +0800, Hangbin Liu wrote: > In comment 173ca26e9b51 ("samples/bpf: add comprehensive ipip, ipip6, > ip6ip6 test") we added ip6ip6 test for bpf tunnel testing. But in commit > 933a741e3b82 ("selftests/bpf: bpf tunnel test.") when we moved it to > the current folder, we didn't add it. > > This patch add the ip6ip6 test back to bpf tunnel test. Since the > underlay network is the same, we can reuse the ipip6 framework directly. > Iperf test is removed as currect framework simplified it in purpose. > > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> > --- > tools/testing/selftests/bpf/test_tunnel.sh | 39 ++++++++++++++++++++-- > 1 file changed, 37 insertions(+), 2 deletions(-) > > diff --git a/tools/testing/selftests/bpf/test_tunnel.sh b/tools/testing/selftests/bpf/test_tunnel.sh > index bd12ec97a44d..76a00d2ef988 100755 > --- a/tools/testing/selftests/bpf/test_tunnel.sh > +++ b/tools/testing/selftests/bpf/test_tunnel.sh > @@ -24,12 +24,12 @@ > # Root namespace with metadata-mode tunnel + BPF > # Device names and addresses: > # veth1 IP: 172.16.1.200, IPv6: 00::22 (underlay) > -# tunnel dev <type>11, ex: gre11, IPv4: 10.1.1.200 (overlay) > +# tunnel dev <type>11, ex: gre11, IPv4: 10.1.1.200, IPv6: 1::22 (overlay) > # > # Namespace at_ns0 with native tunnel > # Device names and addresses: > # veth0 IPv4: 172.16.1.100, IPv6: 00::11 (underlay) > -# tunnel dev <type>00, ex: gre00, IPv4: 10.1.1.100 (overlay) > +# tunnel dev <type>00, ex: gre00, IPv4: 10.1.1.100, IPv6: 1::11 (overlay) > # > # > # End-to-end ping packet flow > @@ -262,11 +262,13 @@ add_ipip6tnl_tunnel() > ip link add dev $DEV_NS type $TYPE \ > local ::11 remote ::22 > ip netns exec at_ns0 ip addr add dev $DEV_NS 10.1.1.100/24 > + ip netns exec at_ns0 ip addr add dev $DEV_NS 1::11/96 > ip netns exec at_ns0 ip link set dev $DEV_NS up > > # root namespace > ip link add dev $DEV type $TYPE external > ip addr add dev $DEV 10.1.1.200/24 > + ip addr add dev $DEV 1::22/96 > ip link set dev $DEV up > } > > @@ -553,6 +555,34 @@ test_ipip6() > echo -e ${GREEN}"PASS: $TYPE"${NC} > } > > +test_ip6ip6() > +{ > + TYPE=ip6tnl > + DEV_NS=ip6ip6tnl00 > + DEV=ip6ip6tnl11 > + ret=0 > + > + check $TYPE > + config_device > + add_ipip6tnl_tunnel > + ip link set dev veth1 mtu 1500 > + attach_bpf $DEV ipip6_set_tunnel ipip6_get_tunnel From looking at the ipip6_set_tunnel in test_tunnel_kern.c. I don't think they are testing an ip6ip6 packet. If the intention is to test ip6ip6, why the existing ip6ip6_set_tunnel does not need to be exercised? > + # underlay > + ping6 $PING_ARG ::11 > + # ip6 over ip6 > + ping6 $PING_ARG 1::11 > + check_err $? > + ip netns exec at_ns0 ping6 $PING_ARG 1::22 > + check_err $? > + cleanup > + > + if [ $ret -ne 0 ]; then > + echo -e ${RED}"FAIL: ip6$TYPE"${NC} > + return 1 > + fi > + echo -e ${GREEN}"PASS: ip6$TYPE"${NC} > +}
On Wed, Nov 04, 2020 at 10:40:34AM -0800, Martin KaFai Lau wrote: > > + check $TYPE > > + config_device > > + add_ipip6tnl_tunnel > > + ip link set dev veth1 mtu 1500 > > + attach_bpf $DEV ipip6_set_tunnel ipip6_get_tunnel > From looking at the ipip6_set_tunnel in test_tunnel_kern.c. > I don't think they are testing an ip6ip6 packet. > If the intention is to test ip6ip6, why the existing > ip6ip6_set_tunnel does not need to be exercised? Hi Martin, Maybe I missed something. But I saw both ipip6_set_tunnel and ip6ip6_set_tunnel in test_tunnel_kern.c. only set remote IPv6 address. They didn't do anything else. The only difference between ipip6 and ip6ip6 are in overlay network, using IPv4 or IPv6. Thanks Hangbin
diff --git a/tools/testing/selftests/bpf/test_tunnel.sh b/tools/testing/selftests/bpf/test_tunnel.sh index bd12ec97a44d..76a00d2ef988 100755 --- a/tools/testing/selftests/bpf/test_tunnel.sh +++ b/tools/testing/selftests/bpf/test_tunnel.sh @@ -24,12 +24,12 @@ # Root namespace with metadata-mode tunnel + BPF # Device names and addresses: # veth1 IP: 172.16.1.200, IPv6: 00::22 (underlay) -# tunnel dev <type>11, ex: gre11, IPv4: 10.1.1.200 (overlay) +# tunnel dev <type>11, ex: gre11, IPv4: 10.1.1.200, IPv6: 1::22 (overlay) # # Namespace at_ns0 with native tunnel # Device names and addresses: # veth0 IPv4: 172.16.1.100, IPv6: 00::11 (underlay) -# tunnel dev <type>00, ex: gre00, IPv4: 10.1.1.100 (overlay) +# tunnel dev <type>00, ex: gre00, IPv4: 10.1.1.100, IPv6: 1::11 (overlay) # # # End-to-end ping packet flow @@ -262,11 +262,13 @@ add_ipip6tnl_tunnel() ip link add dev $DEV_NS type $TYPE \ local ::11 remote ::22 ip netns exec at_ns0 ip addr add dev $DEV_NS 10.1.1.100/24 + ip netns exec at_ns0 ip addr add dev $DEV_NS 1::11/96 ip netns exec at_ns0 ip link set dev $DEV_NS up # root namespace ip link add dev $DEV type $TYPE external ip addr add dev $DEV 10.1.1.200/24 + ip addr add dev $DEV 1::22/96 ip link set dev $DEV up } @@ -553,6 +555,34 @@ test_ipip6() echo -e ${GREEN}"PASS: $TYPE"${NC} } +test_ip6ip6() +{ + TYPE=ip6tnl + DEV_NS=ip6ip6tnl00 + DEV=ip6ip6tnl11 + ret=0 + + check $TYPE + config_device + add_ipip6tnl_tunnel + ip link set dev veth1 mtu 1500 + attach_bpf $DEV ipip6_set_tunnel ipip6_get_tunnel + # underlay + ping6 $PING_ARG ::11 + # ip6 over ip6 + ping6 $PING_ARG 1::11 + check_err $? + ip netns exec at_ns0 ping6 $PING_ARG 1::22 + check_err $? + cleanup + + if [ $ret -ne 0 ]; then + echo -e ${RED}"FAIL: ip6$TYPE"${NC} + return 1 + fi + echo -e ${GREEN}"PASS: ip6$TYPE"${NC} +} + setup_xfrm_tunnel() { auth=0x$(printf '1%.0s' {1..40}) @@ -646,6 +676,7 @@ cleanup() ip link del veth1 2> /dev/null ip link del ipip11 2> /dev/null ip link del ipip6tnl11 2> /dev/null + ip link del ip6ip6tnl11 2> /dev/null ip link del gretap11 2> /dev/null ip link del ip6gre11 2> /dev/null ip link del ip6gretap11 2> /dev/null @@ -742,6 +773,10 @@ bpf_tunnel_test() test_ipip6 errors=$(( $errors + $? )) + echo "Testing IP6IP6 tunnel..." + test_ip6ip6 + errors=$(( $errors + $? )) + echo "Testing IPSec tunnel..." test_xfrm_tunnel errors=$(( $errors + $? ))
In comment 173ca26e9b51 ("samples/bpf: add comprehensive ipip, ipip6, ip6ip6 test") we added ip6ip6 test for bpf tunnel testing. But in commit 933a741e3b82 ("selftests/bpf: bpf tunnel test.") when we moved it to the current folder, we didn't add it. This patch add the ip6ip6 test back to bpf tunnel test. Since the underlay network is the same, we can reuse the ipip6 framework directly. Iperf test is removed as currect framework simplified it in purpose. Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> --- tools/testing/selftests/bpf/test_tunnel.sh | 39 ++++++++++++++++++++-- 1 file changed, 37 insertions(+), 2 deletions(-)