Re: [PATCH net-next v9] openvswitch: enable NSH support

quoted

The optimization Yi refers to only affects the slow path translation.

OVS 2.8 does not immediately trigger an immediate recirculation after translating
encap(nsh,...). There is no need to do so as the flow key of the resulting packet
can be determined from the encap() action and its properties. Translation
continues with the rewritten flow key and subsequent OpenFlow actions will
typically set the new fields in the new NSH header. The push_nsh datapath action
(including all NSH header fields) is only generated at the next commit, e.g. for
output, cloning, recirculation, encap/decap or another destructive change of
the flow key.

The implementation of push_nsh in the user-space datapath does not update
the miniflow (key) of the packet, only the packet data and some metadata.
If the packet needs to be looked up again the slow path triggers recirculation
to re-parse the packet. There should be no need for the datapath push_nsh
action to try to update the flow key.

Thanks Jan for clarification, it can still work after removing that
line, our flows didn't match it after push_nsh, it is output to
VxLAN-gpe port after push_nsh, I'm not sure if we can match dl_type and NSH
fields if we don't output and don't recirculate.

No worries, a packet cannot be matched again in the datapath unless it is 
recirculated. And recirculation today always implies re-parsing. 

In the future we want to look into possibilities to optimize performance of 
recirculation, for example by skipping the parsing stage if it is unnecessary.
For that we may need to invalidate the flow key in packet metadata when
the packet is modified without corresponding update of the key itself. But that
is music of the future.

/Jan