All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonas Bonn <jonas@norrbonn.se>
To: laforge@gnumonks.org, netdev@vger.kernel.org, pbshelar@fb.com,
	kuba@kernel.org
Cc: pablo@netfilter.org
Subject: Re: [RFC PATCH 14/16] gtp: add support for flow based tunneling
Date: Mon, 25 Jan 2021 09:47:45 +0100	[thread overview]
Message-ID: <c9331481-4b6b-4451-d54b-93a1b31680dc@norrbonn.se> (raw)
In-Reply-To: <20210123195916.2765481-15-jonas@norrbonn.se>

Hi Pravin,

On 23/01/2021 20:59, Jonas Bonn wrote:
> From: Pravin B Shelar <pbshelar@fb.com>
> 
> @@ -617,29 +686,84 @@ static void gtp_push_header(struct sk_buff *skb, struct pdp_ctx *pctx,
>   static int gtp_xmit_ip4(struct sk_buff *skb, struct net_device *dev)
>   {
>   	struct gtp_dev *gtp = netdev_priv(dev);
> +	struct gtpu_metadata *opts = NULL;
> +	struct pdp_ctx md_pctx;
>   	struct pdp_ctx *pctx;
> +	__be16 port;
>   	struct rtable *rt;
> -	__be32 saddr;
>   	struct iphdr *iph;
> +	__be32 saddr;
>   	int headroom;
> -	__be16 port;
> +	__u8 tos;
>   	int r;
>   
> -	/* Read the IP destination address and resolve the PDP context.
> -	 * Prepend PDP header with TEI/TID from PDP ctx.
> -	 */
> -	iph = ip_hdr(skb);
> -	if (gtp->role == GTP_ROLE_SGSN)
> -		pctx = ipv4_pdp_find(gtp, iph->saddr);
> -	else
> -		pctx = ipv4_pdp_find(gtp, iph->daddr);
> +	if (gtp->collect_md) {

Why do we have this restriction that the device be exclusively "collect 
metadata" mode or PDP context mode?  Why are we not able to mix the two?

Furthermore, since the collect_md_sock will effectively always be 
listening on INADDR_ANY, that precludes any other PDP context devices 
from co-existing with it.  So setting up a secondary device for PDP 
contexts isn't a feasible workaround.

If mixing isn't possible, then I suppose PDP context management needs to 
be made to fail gracefully in "collect_md" mode... with the current 
patches I think that contexts can be set up but they are just silently 
ignored, which seems like a potential source of confusion.

/Jonas


> +		/* LWT GTP1U encap */
> +		struct ip_tunnel_info *info = NULL;
>   
> -	if (!pctx) {
> -		netdev_dbg(dev, "no PDP ctx found for %pI4, skip\n",
> -			   &iph->daddr);
> -		return -ENOENT;
> +		info = skb_tunnel_info(skb);
> +		if (!info) {
> +			netdev_dbg(dev, "missing tunnel info");
> +			return -ENOENT;
> +		}
> +		if (info->key.tp_dst && ntohs(info->key.tp_dst) != GTP1U_PORT) {
> +			netdev_dbg(dev, "unexpected GTP dst port: %d", ntohs(info->key.tp_dst));
> +			return -EOPNOTSUPP;
> +		}
> +
> +		if (!gtp->sk1u) {
> +			netdev_dbg(dev, "missing tunnel sock");
> +			return -EOPNOTSUPP;
> +		}
> +
> +		pctx = &md_pctx;
> +		memset(pctx, 0, sizeof(*pctx));
> +		pctx->sk = gtp->sk1u;
> +		pctx->gtp_version = GTP_V1;
> +		pctx->u.v1.o_tei = ntohl(tunnel_id_to_key32(info->key.tun_id));
> +		pctx->peer_addr_ip4.s_addr = info->key.u.ipv4.dst;
> +
> +		saddr = info->key.u.ipv4.src;
> +		tos = info->key.tos;
> +
> +		if (info->options_len != 0) {
> +			if (info->key.tun_flags & TUNNEL_GTPU_OPT) {
> +				opts = ip_tunnel_info_opts(info);
> +			} else {
> +				netdev_dbg(dev, "missing tunnel metadata for control pkt");
> +				return -EOPNOTSUPP;
> +			}
> +		}
> +		netdev_dbg(dev, "flow-based GTP1U encap: tunnel id %d\n",
> +			   pctx->u.v1.o_tei);
> +	} else {
> +		struct iphdr *iph;
> +
> +		if (ntohs(skb->protocol) != ETH_P_IP)
> +			return -EOPNOTSUPP;
> +
> +		iph = ip_hdr(skb);
> +
> +		/* Read the IP destination address and resolve the PDP context.
> +		 * Prepend PDP header with TEI/TID from PDP ctx.
> +		 */
> +		if (gtp->role == GTP_ROLE_SGSN)
> +			pctx = ipv4_pdp_find(gtp, iph->saddr);
> +		else
> +			pctx = ipv4_pdp_find(gtp, iph->daddr);
> +
> +		if (!pctx) {
> +			netdev_dbg(dev, "no PDP ctx found for %pI4, skip\n",
> +				   &iph->daddr);
> +			return -ENOENT;
> +		}
> +		netdev_dbg(dev, "found PDP context %p\n", pctx);
> +
> +		saddr = inet_sk(pctx->sk)->inet_saddr;
> +		tos = iph->tos;
> +		netdev_dbg(dev, "gtp -> IP src: %pI4 dst: %pI4\n",
> +			   &iph->saddr, &iph->daddr);
>   	}
> -	netdev_dbg(dev, "found PDP context %p\n", pctx);
>   
>   	rt = gtp_get_v4_rt(skb, dev, pctx, &saddr);
>   	if (IS_ERR(rt)) {
> @@ -691,7 +815,7 @@ static int gtp_xmit_ip4(struct sk_buff *skb, struct net_device *dev)
>   
>   	udp_tunnel_xmit_skb(rt, pctx->sk, skb,
>   			    saddr, pctx->peer_addr_ip4.s_addr,
> -			    iph->tos,
> +			    tos,
>   			    ip4_dst_hoplimit(&rt->dst),
>   			    0,
>   			    port, port,
> diff --git a/include/uapi/linux/gtp.h b/include/uapi/linux/gtp.h
> index 79f9191bbb24..62aff78b7c56 100644
> --- a/include/uapi/linux/gtp.h
> +++ b/include/uapi/linux/gtp.h
> @@ -2,6 +2,8 @@
>   #ifndef _UAPI_LINUX_GTP_H_
>   #define _UAPI_LINUX_GTP_H_
>   
> +#include <linux/types.h>
> +
>   #define GTP_GENL_MCGRP_NAME	"gtp"
>   
>   enum gtp_genl_cmds {
> @@ -34,4 +36,14 @@ enum gtp_attrs {
>   };
>   #define GTPA_MAX (__GTPA_MAX + 1)
>   
> +enum {
> +	GTP_METADATA_V1
> +};
> +
> +struct gtpu_metadata {
> +	__u8    ver;
> +	__u8    flags;
> +	__u8    type;
> +};
> +
>   #endif /* _UAPI_LINUX_GTP_H_ */
> diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
> index 7d9105533c7b..802da679fab1 100644
> --- a/include/uapi/linux/if_tunnel.h
> +++ b/include/uapi/linux/if_tunnel.h
> @@ -176,6 +176,7 @@ enum {
>   #define TUNNEL_VXLAN_OPT	__cpu_to_be16(0x1000)
>   #define TUNNEL_NOCACHE		__cpu_to_be16(0x2000)
>   #define TUNNEL_ERSPAN_OPT	__cpu_to_be16(0x4000)
> +#define TUNNEL_GTPU_OPT		__cpu_to_be16(0x8000)
>   
>   #define TUNNEL_OPTIONS_PRESENT \
>   		(TUNNEL_GENEVE_OPT | TUNNEL_VXLAN_OPT | TUNNEL_ERSPAN_OPT)
> diff --git a/tools/include/uapi/linux/if_link.h b/tools/include/uapi/linux/if_link.h
> index d208b2af697f..28d649bda686 100644
> --- a/tools/include/uapi/linux/if_link.h
> +++ b/tools/include/uapi/linux/if_link.h
> @@ -617,6 +617,7 @@ enum {
>   	IFLA_GTP_FD1,
>   	IFLA_GTP_PDP_HASHSIZE,
>   	IFLA_GTP_ROLE,
> +	IFLA_GTP_COLLECT_METADATA,
>   	__IFLA_GTP_MAX,
>   };
>   #define IFLA_GTP_MAX (__IFLA_GTP_MAX - 1)
> 

  parent reply	other threads:[~2021-01-26  4:48 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-23 19:59 [RFC PATCH 00/16] GTP: flow based Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 01/16] Revert "GTP: add support for flow based tunneling API" Jonas Bonn
2021-01-24 16:34   ` Harald Welte
2021-01-23 19:59 ` [RFC PATCH 02/16] gtp: set initial MTU Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 03/16] gtp: include role in link info Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 04/16] gtp: really check namespaces before xmit Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 05/16] gtp: drop unnecessary call to skb_dst_drop Jonas Bonn
2021-01-24 16:48   ` Harald Welte
2021-01-23 19:59 ` [RFC PATCH 06/16] gtp: set device type Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 07/16] gtp: rework IPv4 functionality Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 08/16] gtp: set dev features to enable GSO Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 09/16] gtp: support GRO Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 10/16] gtp: refactor check_ms back into version specific handlers Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 11/16] gtp: drop duplicated assignment Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 12/16] gtp: update rx_length_errors for abnormally short packets Jonas Bonn
2021-01-24 16:50   ` Harald Welte
2021-01-23 19:59 ` [RFC PATCH 13/16] gtp: set skb protocol after pulling headers Jonas Bonn
2021-01-23 19:59 ` [RFC PATCH 14/16] gtp: add support for flow based tunneling Jonas Bonn
2021-01-24 14:27   ` Jonas Bonn
2021-01-24 15:11   ` Jonas Bonn
2021-01-25  8:12   ` Jonas Bonn
2021-01-25  8:47   ` Jonas Bonn [this message]
2021-02-06 18:04   ` Jonas Bonn
2021-02-07 17:56     ` Pravin Shelar
2021-01-23 19:59 ` [RFC PATCH 15/16] gtp: add ability to send GTP controls headers Jonas Bonn
2021-01-24 14:21   ` Jonas Bonn
2021-01-25 17:41     ` Harald Welte
2021-01-28 21:29       ` Pravin Shelar
2021-01-28 21:29     ` Pravin Shelar
     [not found]       ` <9b9476d2-186f-e749-f17d-d191c30347e4@norrbonn.se>
2021-01-30  6:59         ` Pravin Shelar
2021-01-30 18:44           ` Jakub Kicinski
2021-01-30 20:05             ` Pravin Shelar
2021-02-01 20:44               ` Jakub Kicinski
2021-02-02  5:24                 ` Jonas Bonn
2021-02-02  6:56                   ` Pravin Shelar
2021-02-02  8:03                     ` Jonas Bonn
2021-02-02 22:54                       ` Pravin Shelar
2021-01-23 19:59 ` [RFC PATCH 16/16] gtp: add netlink support for setting up flow based tunnels Jonas Bonn
2021-01-24 17:42 ` [RFC PATCH 00/16] GTP: flow based Pravin Shelar

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=c9331481-4b6b-4451-d54b-93a1b31680dc@norrbonn.se \
    --to=jonas@norrbonn.se \
    --cc=kuba@kernel.org \
    --cc=laforge@gnumonks.org \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=pbshelar@fb.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.