> > 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