Hi Jesse, Simon, It is great to see this work moving forward !
There is one cosmetic thing that we may want to address, which is how to name these ports. - I believe that it is better to avoid the l3 port naming, since they will apply to all protocols that can be designated with an ethertype, and some of these are not L3 (MPLS is a typical example). - "non-tap" is a possible name, but not everyone knows that tap means Ethernet
- "non-ethernet" would actually describe pretty acurately what the port does Anyhow, "non-tap" is better than l3 and we can live with this name. 27/01/2016-01-27 07:09, Jesse Gross :
It seems like it would be ideal if we can avoid creating a new port type for each of these possible combinations and somehow just make the flow keys look right. After all, in the case of GRE, we already support all of the inner protocols that I mentioned about through the main flow lookup so it would be cool if after decapsulation the appropriate packet came out with the addition of GRE metadata.
Choosing between the two behaviors with an option rather than with different type is also the choice I had done in the patched that I had tried to cook some time ago based on Lorand Jakab l3port patch. I agree with the rationale above that it will help avoid code duplication to support the same thing for Geneve, GPE etc.
One thing though: the piece of code mapping incoming GRE traffic to tunnel ports (when more than one is defined) will need to know if tunnel port are tap or non-tap to do the right thing. I don't know if that will be equally easy if this information is stored as an option or using addtional tunnel types.
Best, -Thomas _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
