[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210201124414.21466bff@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Mon, 1 Feb 2021 12:44:14 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Pravin Shelar <pravin.ovn@...il.com>
Cc: Jonas Bonn <jonas@...rbonn.se>,
Harald Welte <laforge@...monks.org>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Pravin B Shelar <pbshelar@...com>,
Pablo Neira Ayuso <pablo@...filter.org>
Subject: Re: [RFC PATCH 15/16] gtp: add ability to send GTP controls headers
On Sat, 30 Jan 2021 12:05:40 -0800 Pravin Shelar wrote:
> On Sat, Jan 30, 2021 at 10:44 AM Jakub Kicinski <kuba@...nel.org> wrote:
> > On Fri, 29 Jan 2021 22:59:06 -0800 Pravin Shelar wrote:
> > > On Fri, Jan 29, 2021 at 6:08 AM Jonas Bonn <jonas@...rbonn.se> wrote:
> > > Following are the reasons for extracting the header and populating metadata.
> > > 1. That is the design used by other tunneling protocols
> > > implementations for handling optional headers. We need to have a
> > > consistent model across all tunnel devices for upper layers.
> >
> > Could you clarify with some examples? This does not match intuition,
> > I must be missing something.
>
> You can look at geneve_rx() or vxlan_rcv() that extracts optional
> headers in ip_tunnel_info opts.
Okay, I got confused what Jonas was inquiring about. I thought that the
extension headers were not pulled, rather than not parsed. Copying them
as-is to info->opts is right, thanks!
Powered by blists - more mailing lists