On Sat, Feb 6, 2021 at 10:06 AM Jonas Bonn wrote:
>
> Hi Pravin et al;
>
> TL;DR: we don't need to introduce an entire collect_md mode to the
> driver; we just need to tweak what we've got so that metadata is
> "always" added on RX and respected on TX; make the userspace socket
> optional and dum
Hi Pravin et al;
TL;DR: we don't need to introduce an entire collect_md mode to the
driver; we just need to tweak what we've got so that metadata is
"always" added on RX and respected on TX; make the userspace socket
optional and dump GTP packets to netstack if it's not present; and make
a d
Hi Pravin,
I'm going to submit a new series without the GTP_METADATA bits. I think
the whole "collect metadata" approach is fine, but the way GTP header
information is passed through the tunnel via metadata needs a bit more
thought. See below...
On 23/01/2021 20:59, Jonas Bonn wrote:
From
Hi Pravin,
On 23/01/2021 20:59, Jonas Bonn wrote:
From: Pravin B Shelar
@@ -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);
+
Hi,
On 23/01/2021 20:59, Jonas Bonn wrote:
From: Pravin B Shelar
This patch adds support for flow based tunneling, allowing to send and
receive GTP tunneled packets via the (lightweight) tunnel metadata
mechanism. This would allow integration with OVS and eBPF using flow
based tunneling APIs.
Hi Pravin,
A couple more comments around the GTP_METADATA bits:
On 23/01/2021 20:59, Jonas Bonn wrote:
From: Pravin B Shelar
This patch adds support for flow based tunneling, allowing to send and
receive GTP tunneled packets via the (lightweight) tunnel metadata
mechanism. This would allow i
From: Pravin B Shelar
This patch adds support for flow based tunneling, allowing to send and
receive GTP tunneled packets via the (lightweight) tunnel metadata
mechanism. This would allow integration with OVS and eBPF using flow
based tunneling APIs.
The mechanism used here is to get the requir
