Hi Joe, > Thanks for taking a look. Andy and I have been throwing some thoughts > around about this, but I'm not sure we came to a concrete solution yet > either. My main thought is that I think that the 'flow' needs to be > modified in the similar way that the 'push_tnl' would work in the > datapath - updating the IP/UDP fields in a protocol-specific manner. > Then the shared code between patch ports and this tunneling > translation needs close attention to check everything is lined up > correctly, restored after output translation, etc.
I agree, the flow and base_flow need to be updated according the tunnel header before applying nested clone actions, then they should be restored. > Given that master is broken, it would be nice to restore it to a good > state. The quickest way to do so would be to revert this patch on > master. Then you could re-propose the patches to achieve this 'direct > translation of tunneling' logic. That said, if you expect this to be > fixed shortly then perhaps we could just wait for a fix. The main > worry I have is that the translation code tends to be pretty > elaborate/subtle so getting a solid fix in this area may take some > time (and my regular tester box has already been complaining at me for > a while now). > > What do you think? I'm happy to give you a bit more time if you think > that's the best approach. I think it's ok if the patch is reverted, then a new patch with fix is going to be sent to the list. Since I'm a co-author, I would like to ask Sugesh as well. Sugesh what do you think? Best regards, Zoltan _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev