Re: [RFC PATCH 15/16] gtp: add ability to send GTP controls headers
From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-02-01 20:44:58
Possibly related (same subject, not in this thread)
- 2021-01-28 · Re: [RFC PATCH 15/16] gtp: add ability to send GTP controls headers · Pravin Shelar <hidden>
- 2021-01-28 · Re: [RFC PATCH 15/16] gtp: add ability to send GTP controls headers · Pravin Shelar <hidden>
- 2021-01-25 · Re: [RFC PATCH 15/16] gtp: add ability to send GTP controls headers · Harald Welte <laforge@gnumonks.org>
- 2021-01-24 · Re: [RFC PATCH 15/16] gtp: add ability to send GTP controls headers · Jonas Bonn <hidden>
- 2021-01-23 · [RFC PATCH 15/16] gtp: add ability to send GTP controls headers · Jonas Bonn <hidden>
On Sat, 30 Jan 2021 12:05:40 -0800 Pravin Shelar wrote:
On Sat, Jan 30, 2021 at 10:44 AM Jakub Kicinski [off-list ref] wrote:quoted
On Fri, 29 Jan 2021 22:59:06 -0800 Pravin Shelar wrote:quoted
On Fri, Jan 29, 2021 at 6:08 AM Jonas Bonn [off-list ref] 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!