On Mon, Apr 22, 2019 at 7:40 PM Y Song <ys114...@gmail.com> wrote:
>
> On Mon, Apr 22, 2019 at 7:58 AM Willem de Bruijn
> <willemdebruijn.ker...@gmail.com> wrote:
> >
> > From: Willem de Bruijn <will...@google.com>
> >
> > So far, all BPF tc tunnel testcases encapsulate in the same network
> > protocol. Add an encap testcase that requires updating skb->protocol.
> >
> > The 6in4 tunnel encapsulates an IPv6 packet inside an IPv4 tunnel.
> > Verify that bpf_skb_net_grow correctly updates skb->protocol to
> > select the right protocol handler in __netif_receive_skb_core.
> >
> > The BPF program should also manually update the link layer header to
> > encode the right network protocol.
> >
> > Signed-off-by: Willem de Bruijn <will...@google.com>
> > ---
> > tools/testing/selftests/bpf/config | 1 +
> > .../selftests/bpf/progs/test_tc_tunnel.c | 55 +++++++++++++++++--
> > tools/testing/selftests/bpf/test_tc_tunnel.sh | 20 ++++++-
> > 3 files changed, 71 insertions(+), 5 deletions(-)
> >
> > diff --git a/tools/testing/selftests/bpf/config
> > b/tools/testing/selftests/bpf/config
> > index 8c976476f6fdc..f7a0744db31e1 100644
> > --- a/tools/testing/selftests/bpf/config
> > +++ b/tools/testing/selftests/bpf/config
> > @@ -33,3 +33,4 @@ CONFIG_MPLS=y
> > CONFIG_NET_MPLS_GSO=m
> > CONFIG_MPLS_ROUTING=m
> > CONFIG_MPLS_IPTUNNEL=m
> > +CONFIG_IPV6_SIT=m
> > diff --git a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
> > b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
> > index ab56a6a72b7a5..94ae1caab2bfc 100644
> > --- a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
> > +++ b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
> > @@ -77,17 +77,43 @@ static __always_inline int encap_ipv4(struct __sk_buff
> > *skb, __u8 encap_proto,
> > struct v4hdr h_outer;
> > struct tcphdr tcph;
> > int olen, l2_len;
> > + int tcp_off;
> > __u64 flags;
> >
> > - if (bpf_skb_load_bytes(skb, ETH_HLEN, &iph_inner,
> > - sizeof(iph_inner)) < 0)
> > - return TC_ACT_OK;
> > + if (encap_proto == IPPROTO_IPV6) {
> > + const __u32 saddr = (192 << 24) | (168 << 16) | (1 << 8) |
> > 1;
> > + const __u32 daddr = (192 << 24) | (168 << 16) | (1 << 8) |
> > 2;
> > + struct ipv6hdr iph6_inner;
> > +
> > + if (bpf_skb_load_bytes(skb, ETH_HLEN, &iph6_inner,
> > + sizeof(iph6_inner)) < 0)
> > + return TC_ACT_OK;
> > +
> > + /* convert to viable ipv4 header */
> > + memset(&iph_inner, 0, sizeof(iph_inner));
> > + iph_inner.version = 4;
> > + iph_inner.ihl = 5;
> > + iph_inner.tot_len = bpf_htons(sizeof(iph6_inner) +
> > + bpf_ntohs(iph6_inner.payload_len));
> > + iph_inner.ttl = iph6_inner.hop_limit - 1;
> > + iph_inner.protocol = iph6_inner.nexthdr;
> > + iph_inner.saddr = __bpf_constant_htonl(saddr);
> > + iph_inner.daddr = __bpf_constant_htonl(daddr);
>
> The code seems correctly. But maybe some variable renaming or
> comments can help improve readability.
>
> For example, here iph_inner (ipv4) intends to represent the
> inner ipv6 and iph_inner.protocol is assigned to iph6_inner.nexthdr
> although it is correctly handled later with h_outer.ip logic.
Thanks for the review. Yes, I added this feature to an already complex
test with 20 variants. Tried to keep the changes as few and local as
possible.
Would it help if I expand the /* convert to viable ipv4 header */
comment? To better explain why we convert to an ipv4 header here
(because all other encap options encap the same protocol, so
encap_ipv4() expects an iphdr instead of an ipv6hdr).
