Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support

quoted

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

Jan Scheurich [off-list ref] writes:

quoted

quoted

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.

Obviously you would use key->tun_opts_len and start appending there and
not simply overwrite. Otherwise that would be rather silly.

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.

Okay, then.

Bye,
Hannes