Hi Jakub,
On 01/02/2021 21:44, Jakub Kicinski wrote:
On Sat, 30 Jan 2021 12:05:40 -0800 Pravin Shelar wrote:
On Sat, Jan 30, 2021 at 10:44 AM Jakub Kicinski <k...@kernel.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 <jo...@norrbonn.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!
No, you're not confused. The extension headers are not being pulled in
the current patchset.
Incoming packet:
---------------------------------------------------------------------
| flags | type | len | TEID | N-PDU | SEQ | Ext | EXT.Hdr | IP | ...
---------------------------------------------------------------------
<--------- GTP header ------<<Optional GTP elements>>-----><- Pkt --->
The "collect metadata" path of the patchset copies 'flags' and 'type' to
info->opts, but leaves the following:
-----------------------------------------
| N-PDU | SEQ | Ext | EXT.Hdr | IP | ...
-----------------------------------------
<--------- GTP header -------><- Pkt --->
So it's leaving _half_ the header and making it a requirement that there
be further intelligence down the line that can handle this. This is far
from intuitive.
/Jonas
