> > There is no way we can re-use the existing TLV tunnel metadata > > infrastructure in OVS for matching and setting NSH MD2 TLV headers. We > > will need to introduce a new (perhaps similar) scheme for modelling > > generic TLV match registers in OVS that are assigned to protocol TLVs > > by the controller. This is FFS. > > This is what I don't understand. > > Why can't you just reuse the space in the struct sw_flow_key where > geneve would put in their metadata. There are 255 empty bytes at the > beginning if you don't have other tunnel metadata anyway. > > If you receive packets over vxlan(gpe), tun_opts gets populated with an > ip_tunnel_key. Couldn't you use the options space in there after the > ip_tunnel_key to store the NSH context just for the sake of storing them > somewhere instead of adding 16 bytes to sw_flow_key?
There is a significant conceptual difference between tunnel metadata (copied from a popped tunnel header) and packed match fields extracted during parsing of the packets. If we'd store them in the same space in the sw_flow_key struct, we are calling for trouble. NSH is transport agnostic, it should work over Ethernet, VXLAN(GPE) and other transport tunnels. Think about an NSH packet arriving on an Geneve tunnel port. Any Geneve tunnel options have already been stored in the tun_opts metadata bytes. Now the datapath parses the NSH header and overwrites the tun_opts metadata with the NSH metadata. This would break the OVS semantics. I absolutely understand your concern about efficient space utilization in the flow struct for TLV match fields and it will be part of the design challenge for MD2 TLV support to find a good balance between memory and run-time efficiency. But that is FFS. For the four fixed size MD1 headers the decision has been to include them as additional attributes in the flow key. BR, Jan
