[PATCH net-next 0/2] gre: add sequence number for collect md mode.

[PATCH net-next 0/2] gre: add sequence number for collect md mode.

[William Tu]

Currently GRE sequence number can only be used in native tunnel mode.
The first patch adds sequence number support for gre collect
metadata mode, and the second patch tests it using BPF.

RFC2890 defines GRE sequence number to be specific to the traffic
flow identified by the key.  However, this patch does not implement
per-key seqno.  The sequence number is shared in the same tunnel
device. That is, different tunnel keys using the same collect_md
tunnel share single sequence number.

A new BFP uapi tunnel flag 'BPF_F_GRE_SEQ' is added.  I name it
since GRE is the only tunnel type having sequence number.

William Tu (2):
  gre: add sequence number for collect md mode.
  samples/bpf: add gre sequence number test.

 include/uapi/linux/bpf.h       |  1 +
 net/core/filter.c              |  4 +++-
 net/ipv4/ip_gre.c              |  7 +++++--
 net/ipv6/ip6_gre.c             | 13 ++++++++-----
 samples/bpf/tcbpf2_kern.c      |  6 ++++--
 samples/bpf/test_tunnel_bpf.sh |  4 ++--
 6 files changed, 23 insertions(+), 12 deletions(-)

-- 
2.7.4

[PATCH net-next 1/2] gre: add sequence number for collect md mode.

[William Tu]

Currently GRE sequence number can only be used in native
tunnel mode.  This patch adds sequence number support for
gre collect metadata mode.  RFC2890 defines GRE sequence
number to be specific to the traffic flow identified by the
key.  However, this patch does not implement per-key seqno.
The sequence number is shared in the same tunnel device.
That is, different tunnel keys using the same collect_md
tunnel share single sequence number.

Signed-off-by: William Tu <u9012063@gmail.com>
---
 include/uapi/linux/bpf.h |  1 +
 net/core/filter.c        |  4 +++-
 net/ipv4/ip_gre.c        |  7 +++++--
 net/ipv6/ip6_gre.c       | 13 ++++++++-----
 4 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index db6bdc375126..2c6dd942953d 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -800,6 +800,7 @@ enum bpf_func_id {
 /* BPF_FUNC_skb_set_tunnel_key flags. */
 #define BPF_F_ZERO_CSUM_TX		(1ULL << 1)
 #define BPF_F_DONT_FRAGMENT		(1ULL << 2)
+#define BPF_F_GRE_SEQ			(1ULL << 3)
 
 /* BPF_FUNC_perf_event_output, BPF_FUNC_perf_event_read and
  * BPF_FUNC_perf_event_read_value flags.
diff --git a/net/core/filter.c b/net/core/filter.c
index 0c121adbdbaa..010305e0791a 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2991,7 +2991,7 @@ BPF_CALL_4(bpf_skb_set_tunnel_key, struct sk_buff *, skb,
 	struct ip_tunnel_info *info;
 
 	if (unlikely(flags & ~(BPF_F_TUNINFO_IPV6 | BPF_F_ZERO_CSUM_TX |
-			       BPF_F_DONT_FRAGMENT)))
+			       BPF_F_DONT_FRAGMENT | BPF_F_GRE_SEQ)))
 		return -EINVAL;
 	if (unlikely(size != sizeof(struct bpf_tunnel_key))) {
 		switch (size) {
@@ -3025,6 +3025,8 @@ BPF_CALL_4(bpf_skb_set_tunnel_key, struct sk_buff *, skb,
 		info->key.tun_flags |= TUNNEL_DONT_FRAGMENT;
 	if (flags & BPF_F_ZERO_CSUM_TX)
 		info->key.tun_flags &= ~TUNNEL_CSUM;
+	if (flags & BPF_F_GRE_SEQ)
+		info->key.tun_flags |= TUNNEL_SEQ;
 
 	info->key.tun_id = cpu_to_be64(from->tunnel_id);
 	info->key.tos = from->tunnel_tos;
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 0fe1d69b5df4..95fd225f402e 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -522,6 +522,7 @@ static struct rtable *prepare_fb_xmit(struct sk_buff *skb,
 static void gre_fb_xmit(struct sk_buff *skb, struct net_device *dev,
 			__be16 proto)
 {
+	struct ip_tunnel *tunnel = netdev_priv(dev);
 	struct ip_tunnel_info *tun_info;
 	const struct ip_tunnel_key *key;
 	struct rtable *rt = NULL;
@@ -545,9 +546,11 @@ static void gre_fb_xmit(struct sk_buff *skb, struct net_device *dev,
 	if (gre_handle_offloads(skb, !!(tun_info->key.tun_flags & TUNNEL_CSUM)))
 		goto err_free_rt;
 
-	flags = tun_info->key.tun_flags & (TUNNEL_CSUM | TUNNEL_KEY);
+	flags = tun_info->key.tun_flags &
+		(TUNNEL_CSUM | TUNNEL_KEY | TUNNEL_SEQ);
 	gre_build_header(skb, tunnel_hlen, flags, proto,
-			 tunnel_id_to_key32(tun_info->key.tun_id), 0);
+			 tunnel_id_to_key32(tun_info->key.tun_id),
+			 (flags | TUNNEL_SEQ) ? htonl(tunnel->o_seqno++) : 0);
 
 	df = key->tun_flags & TUNNEL_DONT_FRAGMENT ?  htons(IP_DF) : 0;
 
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 4f150a394387..16c5dfcbd195 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -695,9 +695,6 @@ static netdev_tx_t __gre6_xmit(struct sk_buff *skb,
 	else
 		fl6->daddr = tunnel->parms.raddr;
 
-	if (tunnel->parms.o_flags & TUNNEL_SEQ)
-		tunnel->o_seqno++;
-
 	/* Push GRE header. */
 	protocol = (dev->type == ARPHRD_ETHER) ? htons(ETH_P_TEB) : proto;
 
@@ -720,14 +717,20 @@ static netdev_tx_t __gre6_xmit(struct sk_buff *skb,
 		fl6->flowi6_uid = sock_net_uid(dev_net(dev), NULL);
 
 		dsfield = key->tos;
-		flags = key->tun_flags & (TUNNEL_CSUM | TUNNEL_KEY);
+		flags = key->tun_flags &
+			(TUNNEL_CSUM | TUNNEL_KEY | TUNNEL_SEQ);
 		tunnel->tun_hlen = gre_calc_hlen(flags);
 
 		gre_build_header(skb, tunnel->tun_hlen,
 				 flags, protocol,
-				 tunnel_id_to_key32(tun_info->key.tun_id), 0);
+				 tunnel_id_to_key32(tun_info->key.tun_id),
+				 (flags | TUNNEL_SEQ) ? htonl(tunnel->o_seqno++)
+						      : 0);
 
 	} else {
+		if (tunnel->parms.o_flags & TUNNEL_SEQ)
+			tunnel->o_seqno++;
+
 		gre_build_header(skb, tunnel->tun_hlen, tunnel->parms.o_flags,
 				 protocol, tunnel->parms.o_key,
 				 htonl(tunnel->o_seqno));
-- 
2.7.4

[PATCH net-next 2/2] samples/bpf: add gre sequence number test.

[William Tu]

The patch adds tests for GRE sequence number
support for metadata mode tunnel.

Signed-off-by: William Tu <u9012063@gmail.com>
---
 samples/bpf/tcbpf2_kern.c      | 6 ++++--
 samples/bpf/test_tunnel_bpf.sh | 4 ++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/samples/bpf/tcbpf2_kern.c b/samples/bpf/tcbpf2_kern.c
index efdc16d195ff..f9d0db2be21b 100644
--- a/samples/bpf/tcbpf2_kern.c
+++ b/samples/bpf/tcbpf2_kern.c
@@ -52,7 +52,8 @@ int _gre_set_tunnel(struct __sk_buff *skb)
 	key.tunnel_tos = 0;
 	key.tunnel_ttl = 64;
 
-	ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key), BPF_F_ZERO_CSUM_TX);
+	ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key),
+				     BPF_F_ZERO_CSUM_TX | BPF_F_GRE_SEQ);
 	if (ret < 0) {
 		ERROR(ret);
 		return TC_ACT_SHOT;
@@ -92,7 +93,8 @@ int _ip6gretap_set_tunnel(struct __sk_buff *skb)
 	key.tunnel_label = 0xabcde;
 
 	ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key),
-				     BPF_F_TUNINFO_IPV6 | BPF_F_ZERO_CSUM_TX);
+				     BPF_F_TUNINFO_IPV6 | BPF_F_ZERO_CSUM_TX |
+				     BPF_F_GRE_SEQ);
 	if (ret < 0) {
 		ERROR(ret);
 		return TC_ACT_SHOT;
diff --git a/samples/bpf/test_tunnel_bpf.sh b/samples/bpf/test_tunnel_bpf.sh
index 43ce049996ee..01a07fb9efa9 100755
--- a/samples/bpf/test_tunnel_bpf.sh
+++ b/samples/bpf/test_tunnel_bpf.sh
@@ -23,7 +23,7 @@ function config_device {
 function add_gre_tunnel {
 	# in namespace
 	ip netns exec at_ns0 \
-		ip link add dev $DEV_NS type $TYPE key 2 local 172.16.1.100 remote 172.16.1.200
+		ip link add dev $DEV_NS type $TYPE seq key 2 local 172.16.1.100 remote 172.16.1.200
 	ip netns exec at_ns0 ip link set dev $DEV_NS up
 	ip netns exec at_ns0 ip addr add dev $DEV_NS 10.1.1.100/24
 
@@ -43,7 +43,7 @@ function add_ip6gretap_tunnel {
 
 	# in namespace
 	ip netns exec at_ns0 \
-		ip link add dev $DEV_NS type $TYPE flowlabel 0xbcdef key 2 \
+		ip link add dev $DEV_NS type $TYPE seq flowlabel 0xbcdef key 2 \
 		local ::11 remote ::22
 
 	ip netns exec at_ns0 ip addr add dev $DEV_NS 10.1.1.100/24
-- 
2.7.4

Re: [PATCH net-next 1/2] gre: add sequence number for collect md mode.

[Daniel Borkmann]

On 03/01/2018 01:11 AM, William Tu wrote:
> Currently GRE sequence number can only be used in native
> tunnel mode.  This patch adds sequence number support for
> gre collect metadata mode.  RFC2890 defines GRE sequence
> number to be specific to the traffic flow identified by the
> key.  However, this patch does not implement per-key seqno.
> The sequence number is shared in the same tunnel device.
> That is, different tunnel keys using the same collect_md
> tunnel share single sequence number.
> 
> Signed-off-by: William Tu <u9012063@gmail.com>
> ---
>  include/uapi/linux/bpf.h |  1 +
>  net/core/filter.c        |  4 +++-
>  net/ipv4/ip_gre.c        |  7 +++++--
>  net/ipv6/ip6_gre.c       | 13 ++++++++-----
>  4 files changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index db6bdc375126..2c6dd942953d 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -800,6 +800,7 @@ enum bpf_func_id {
>  /* BPF_FUNC_skb_set_tunnel_key flags. */
>  #define BPF_F_ZERO_CSUM_TX		(1ULL << 1)
>  #define BPF_F_DONT_FRAGMENT		(1ULL << 2)
> +#define BPF_F_GRE_SEQ			(1ULL << 3)
>  
>  /* BPF_FUNC_perf_event_output, BPF_FUNC_perf_event_read and
>   * BPF_FUNC_perf_event_read_value flags.
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 0c121adbdbaa..010305e0791a 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -2991,7 +2991,7 @@ BPF_CALL_4(bpf_skb_set_tunnel_key, struct sk_buff *, skb,
>  	struct ip_tunnel_info *info;
>  
>  	if (unlikely(flags & ~(BPF_F_TUNINFO_IPV6 | BPF_F_ZERO_CSUM_TX |
> -			       BPF_F_DONT_FRAGMENT)))
> +			       BPF_F_DONT_FRAGMENT | BPF_F_GRE_SEQ)))
>  		return -EINVAL;
>  	if (unlikely(size != sizeof(struct bpf_tunnel_key))) {
>  		switch (size) {
> @@ -3025,6 +3025,8 @@ BPF_CALL_4(bpf_skb_set_tunnel_key, struct sk_buff *, skb,
>  		info->key.tun_flags |= TUNNEL_DONT_FRAGMENT;
>  	if (flags & BPF_F_ZERO_CSUM_TX)
>  		info->key.tun_flags &= ~TUNNEL_CSUM;
> +	if (flags & BPF_F_GRE_SEQ)
> +		info->key.tun_flags |= TUNNEL_SEQ;

Ok, looks fine. My only minor request would be to rename BPF_F_GRE_SEQ
into e.g. BPF_F_SEQ_NUMBER to at least not have something GRE specific
in the name in case we could later on reuse it elsewhere as well, and
the bpf_skb_set_tunnel_key() is unaware of the underlying encap anyway.

>  	info->key.tun_id = cpu_to_be64(from->tunnel_id);
>  	info->key.tos = from->tunnel_tos;
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 0fe1d69b5df4..95fd225f402e 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -522,6 +522,7 @@ static struct rtable *prepare_fb_xmit(struct sk_buff *skb,
>  static void gre_fb_xmit(struct sk_buff *skb, struct net_device *dev,
>  			__be16 proto)
>  {
> +	struct ip_tunnel *tunnel = netdev_priv(dev);
>  	struct ip_tunnel_info *tun_info;
>  	const struct ip_tunnel_key *key;
>  	struct rtable *rt = NULL;
> @@ -545,9 +546,11 @@ static void gre_fb_xmit(struct sk_buff *skb, struct net_device *dev,
>  	if (gre_handle_offloads(skb, !!(tun_info->key.tun_flags & TUNNEL_CSUM)))
>  		goto err_free_rt;
>  
> -	flags = tun_info->key.tun_flags & (TUNNEL_CSUM | TUNNEL_KEY);
> +	flags = tun_info->key.tun_flags &
> +		(TUNNEL_CSUM | TUNNEL_KEY | TUNNEL_SEQ);
>  	gre_build_header(skb, tunnel_hlen, flags, proto,
> -			 tunnel_id_to_key32(tun_info->key.tun_id), 0);
> +			 tunnel_id_to_key32(tun_info->key.tun_id),
> +			 (flags | TUNNEL_SEQ) ? htonl(tunnel->o_seqno++) : 0);
>  
>  	df = key->tun_flags & TUNNEL_DONT_FRAGMENT ?  htons(IP_DF) : 0;
>  
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index 4f150a394387..16c5dfcbd195 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -695,9 +695,6 @@ static netdev_tx_t __gre6_xmit(struct sk_buff *skb,
>  	else
>  		fl6->daddr = tunnel->parms.raddr;
>  
> -	if (tunnel->parms.o_flags & TUNNEL_SEQ)
> -		tunnel->o_seqno++;
> -
>  	/* Push GRE header. */
>  	protocol = (dev->type == ARPHRD_ETHER) ? htons(ETH_P_TEB) : proto;
>  
> @@ -720,14 +717,20 @@ static netdev_tx_t __gre6_xmit(struct sk_buff *skb,
>  		fl6->flowi6_uid = sock_net_uid(dev_net(dev), NULL);
>  
>  		dsfield = key->tos;
> -		flags = key->tun_flags & (TUNNEL_CSUM | TUNNEL_KEY);
> +		flags = key->tun_flags &
> +			(TUNNEL_CSUM | TUNNEL_KEY | TUNNEL_SEQ);
>  		tunnel->tun_hlen = gre_calc_hlen(flags);
>  
>  		gre_build_header(skb, tunnel->tun_hlen,
>  				 flags, protocol,
> -				 tunnel_id_to_key32(tun_info->key.tun_id), 0);
> +				 tunnel_id_to_key32(tun_info->key.tun_id),
> +				 (flags | TUNNEL_SEQ) ? htonl(tunnel->o_seqno++)
> +						      : 0);
>  
>  	} else {
> +		if (tunnel->parms.o_flags & TUNNEL_SEQ)
> +			tunnel->o_seqno++;
> +
>  		gre_build_header(skb, tunnel->tun_hlen, tunnel->parms.o_flags,
>  				 protocol, tunnel->parms.o_key,
>  				 htonl(tunnel->o_seqno));
> 

Re: [PATCH net-next 2/2] samples/bpf: add gre sequence number test.

[Daniel Borkmann]

On 03/01/2018 01:11 AM, William Tu wrote:
> The patch adds tests for GRE sequence number
> support for metadata mode tunnel.
> 
> Signed-off-by: William Tu <u9012063@gmail.com>
> ---
>  samples/bpf/tcbpf2_kern.c      | 6 ++++--
>  samples/bpf/test_tunnel_bpf.sh | 4 ++--
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/samples/bpf/tcbpf2_kern.c b/samples/bpf/tcbpf2_kern.c
> index efdc16d195ff..f9d0db2be21b 100644
> --- a/samples/bpf/tcbpf2_kern.c
> +++ b/samples/bpf/tcbpf2_kern.c
> @@ -52,7 +52,8 @@ int _gre_set_tunnel(struct __sk_buff *skb)
>  	key.tunnel_tos = 0;
>  	key.tunnel_ttl = 64;
>  
> -	ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key), BPF_F_ZERO_CSUM_TX);
> +	ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key),
> +				     BPF_F_ZERO_CSUM_TX | BPF_F_GRE_SEQ);
>  	if (ret < 0) {
>  		ERROR(ret);
>  		return TC_ACT_SHOT;
> @@ -92,7 +93,8 @@ int _ip6gretap_set_tunnel(struct __sk_buff *skb)
>  	key.tunnel_label = 0xabcde;
>  
>  	ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key),
> -				     BPF_F_TUNINFO_IPV6 | BPF_F_ZERO_CSUM_TX);
> +				     BPF_F_TUNINFO_IPV6 | BPF_F_ZERO_CSUM_TX |
> +				     BPF_F_GRE_SEQ);
>  	if (ret < 0) {
>  		ERROR(ret);
>  		return TC_ACT_SHOT;
> diff --git a/samples/bpf/test_tunnel_bpf.sh b/samples/bpf/test_tunnel_bpf.sh
> index 43ce049996ee..01a07fb9efa9 100755
> --- a/samples/bpf/test_tunnel_bpf.sh
> +++ b/samples/bpf/test_tunnel_bpf.sh

Can be as follow-up, but if you have a chance of moving this into BPF kselftests,
this would be really great. Otherwise this will get little actual test coverage.

Thanks,
Daniel

> @@ -23,7 +23,7 @@ function config_device {
>  function add_gre_tunnel {
>  	# in namespace
>  	ip netns exec at_ns0 \
> -		ip link add dev $DEV_NS type $TYPE key 2 local 172.16.1.100 remote 172.16.1.200
> +		ip link add dev $DEV_NS type $TYPE seq key 2 local 172.16.1.100 remote 172.16.1.200
>  	ip netns exec at_ns0 ip link set dev $DEV_NS up
>  	ip netns exec at_ns0 ip addr add dev $DEV_NS 10.1.1.100/24
>  
> @@ -43,7 +43,7 @@ function add_ip6gretap_tunnel {
>  
>  	# in namespace
>  	ip netns exec at_ns0 \
> -		ip link add dev $DEV_NS type $TYPE flowlabel 0xbcdef key 2 \
> +		ip link add dev $DEV_NS type $TYPE seq flowlabel 0xbcdef key 2 \
>  		local ::11 remote ::22
>  
>  	ip netns exec at_ns0 ip addr add dev $DEV_NS 10.1.1.100/24
> 

Re: [PATCH net-next 1/2] gre: add sequence number for collect md mode.

[William Tu]

On Thu, Mar 1, 2018 at 2:18 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 03/01/2018 01:11 AM, William Tu wrote:
>> Currently GRE sequence number can only be used in native
>> tunnel mode.  This patch adds sequence number support for
>> gre collect metadata mode.  RFC2890 defines GRE sequence
>> number to be specific to the traffic flow identified by the
>> key.  However, this patch does not implement per-key seqno.
>> The sequence number is shared in the same tunnel device.
>> That is, different tunnel keys using the same collect_md
>> tunnel share single sequence number.
>>
>> Signed-off-by: William Tu <u9012063@gmail.com>
>> ---
>>  include/uapi/linux/bpf.h |  1 +
>>  net/core/filter.c        |  4 +++-
>>  net/ipv4/ip_gre.c        |  7 +++++--
>>  net/ipv6/ip6_gre.c       | 13 ++++++++-----
>>  4 files changed, 17 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index db6bdc375126..2c6dd942953d 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -800,6 +800,7 @@ enum bpf_func_id {
>>  /* BPF_FUNC_skb_set_tunnel_key flags. */
>>  #define BPF_F_ZERO_CSUM_TX           (1ULL << 1)
>>  #define BPF_F_DONT_FRAGMENT          (1ULL << 2)
>> +#define BPF_F_GRE_SEQ                        (1ULL << 3)
>>
>>  /* BPF_FUNC_perf_event_output, BPF_FUNC_perf_event_read and
>>   * BPF_FUNC_perf_event_read_value flags.
>> diff --git a/net/core/filter.c b/net/core/filter.c
>> index 0c121adbdbaa..010305e0791a 100644
>> --- a/net/core/filter.c
>> +++ b/net/core/filter.c
>> @@ -2991,7 +2991,7 @@ BPF_CALL_4(bpf_skb_set_tunnel_key, struct sk_buff *, skb,
>>       struct ip_tunnel_info *info;
>>
>>       if (unlikely(flags & ~(BPF_F_TUNINFO_IPV6 | BPF_F_ZERO_CSUM_TX |
>> -                            BPF_F_DONT_FRAGMENT)))
>> +                            BPF_F_DONT_FRAGMENT | BPF_F_GRE_SEQ)))
>>               return -EINVAL;
>>       if (unlikely(size != sizeof(struct bpf_tunnel_key))) {
>>               switch (size) {
>> @@ -3025,6 +3025,8 @@ BPF_CALL_4(bpf_skb_set_tunnel_key, struct sk_buff *, skb,
>>               info->key.tun_flags |= TUNNEL_DONT_FRAGMENT;
>>       if (flags & BPF_F_ZERO_CSUM_TX)
>>               info->key.tun_flags &= ~TUNNEL_CSUM;
>> +     if (flags & BPF_F_GRE_SEQ)
>> +             info->key.tun_flags |= TUNNEL_SEQ;
>
> Ok, looks fine. My only minor request would be to rename BPF_F_GRE_SEQ
> into e.g. BPF_F_SEQ_NUMBER to at least not have something GRE specific
> in the name in case we could later on reuse it elsewhere as well, and
> the bpf_skb_set_tunnel_key() is unaware of the underlying encap anyway.

OK, make sense. Thanks!
I will rename it in the next version.
William

Re: [PATCH net-next 2/2] samples/bpf: add gre sequence number test.

[William Tu]

On Thu, Mar 1, 2018 at 2:30 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 03/01/2018 01:11 AM, William Tu wrote:
>> The patch adds tests for GRE sequence number
>> support for metadata mode tunnel.
>>
>> Signed-off-by: William Tu <u9012063@gmail.com>
>> ---
>>  samples/bpf/tcbpf2_kern.c      | 6 ++++--
>>  samples/bpf/test_tunnel_bpf.sh | 4 ++--
>>  2 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/samples/bpf/tcbpf2_kern.c b/samples/bpf/tcbpf2_kern.c
>> index efdc16d195ff..f9d0db2be21b 100644
>> --- a/samples/bpf/tcbpf2_kern.c
>> +++ b/samples/bpf/tcbpf2_kern.c
>> @@ -52,7 +52,8 @@ int _gre_set_tunnel(struct __sk_buff *skb)
>>       key.tunnel_tos = 0;
>>       key.tunnel_ttl = 64;
>>
>> -     ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key), BPF_F_ZERO_CSUM_TX);
>> +     ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key),
>> +                                  BPF_F_ZERO_CSUM_TX | BPF_F_GRE_SEQ);
>>       if (ret < 0) {
>>               ERROR(ret);
>>               return TC_ACT_SHOT;
>> @@ -92,7 +93,8 @@ int _ip6gretap_set_tunnel(struct __sk_buff *skb)
>>       key.tunnel_label = 0xabcde;
>>
>>       ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key),
>> -                                  BPF_F_TUNINFO_IPV6 | BPF_F_ZERO_CSUM_TX);
>> +                                  BPF_F_TUNINFO_IPV6 | BPF_F_ZERO_CSUM_TX |
>> +                                  BPF_F_GRE_SEQ);
>>       if (ret < 0) {
>>               ERROR(ret);
>>               return TC_ACT_SHOT;
>> diff --git a/samples/bpf/test_tunnel_bpf.sh b/samples/bpf/test_tunnel_bpf.sh
>> index 43ce049996ee..01a07fb9efa9 100755
>> --- a/samples/bpf/test_tunnel_bpf.sh
>> +++ b/samples/bpf/test_tunnel_bpf.sh
>
> Can be as follow-up, but if you have a chance of moving this into BPF kselftests,
> this would be really great. Otherwise this will get little actual test coverage.
>
> Thanks,
> Daniel
>

Yes, this tunnel test is getting bigger and bigger, and it's better to
move to ksefltests.
I will work on it this month.
Thanks!
William

Re: [PATCH net-next 2/2] samples/bpf: add gre sequence number test.

[Daniel Borkmann]

On 03/01/2018 06:19 PM, William Tu wrote:
> On Thu, Mar 1, 2018 at 2:30 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 03/01/2018 01:11 AM, William Tu wrote:
[...]
>>> diff --git a/samples/bpf/test_tunnel_bpf.sh b/samples/bpf/test_tunnel_bpf.sh
>>> index 43ce049996ee..01a07fb9efa9 100755
>>> --- a/samples/bpf/test_tunnel_bpf.sh
>>> +++ b/samples/bpf/test_tunnel_bpf.sh
>>
>> Can be as follow-up, but if you have a chance of moving this into BPF kselftests,
>> this would be really great. Otherwise this will get little actual test coverage.
>>
> Yes, this tunnel test is getting bigger and bigger, and it's better to
> move to ksefltests.
> I will work on it this month.

Great, thanks William!