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: > > > On 28/01/2021 22:29, Pravin Shelar wrote: > > > > Receive path: LWT extracts tunnel metadata into tunnel-metadata > > > > struct. This object has 5-tuple info from outer header and tunnel key. > > > > When there is presence of extension header there is no way to store > > > > the info standard tunnel-metadata object. That is when the optional > > > > section of tunnel-metadata comes in the play. > > > > As you can see the packet data from GTP header onwards is still pushed > > > > to the device, so consumers of LWT can look at tunnel-metadata and > > > > make sense of the inner packet that is received on the device. > > > > OVS does exactly the same. When it receives a GTP packet with optional > > > > metadata, it looks at flags and parses the inner packet and extension > > > > header accordingly. > > > > > > Ah, ok, I see. So you are pulling _half_ of the GTP header off the > > > packet but leaving the optional GTP extension headers in place if they > > > exist. So what OVS receives is a packet with metadata indicating > > > whether or not it begins with these extension headers or whether it > > > begins with an IP header. > > > > > > So OVS might need to begin by pulling parts of the packet in order to > > > get to the inner IP packet. In that case, why don't you just leave the > > > _entire_ GTP header in place and let OVS work from that? The header > > > contains exactly the data you've copied to the metadata struct PLUS it > > > has the incoming TEID value that you really should be validating inner > > > IP against. > > > > > > > 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.
