> Yes, I'd like to help here. Can you shoot me any ideas you may have? > I've been looking at this in my free time today. Tomorrow I should be > able to dedicate most of the day to it.
Ok sounds good. Thanks for taking this on. So at a high level, conceptually what we need to do is fairly straight forward. Instead of creating a vxlan tnl_backer, like we do for the other tunnel types. We need to create a vxlan tnl_backer per dest port. All vxlan ports using the same dest port, will share this backer. So to start off we need to make some minor netdev-vport changes. netdev_vport_get_dpif_port() needs to return special dpif port names for VXLAN ports which embed the dst port number. I.E. instead of "vxlan_system" which it returns now, it would return "vxlan_sys_8472" or "vxlan_sys_4321" depending on what the dest port is. This done, ofproto-dpif and dpif-linux will know that they should be using different tnl_backers. Also, dpif-linux needs to get the dst port from the netdev_tunnel_config and set it in the options if nonzero. The hardest part to deal with will be ofproto-dpif. We're now breaking the assumption that a port's dpif_port can never change once created. Therefore, simply creating and deleting tnl_backers at ofport creation and deletion time will be insufficient as it will not properly deal with dst port config changes. My tentative solution to the problem is to decouple port creation and deletion from tnl_backer management. Specifically, I think we should remove may_dpif_port_del(), and stop doing dpif_port_del() of tnl_backers in the port_del() and port_destruct() functions. Instead we should centralize all of this in a run function near the reconfiguration code. We should loop through all ofports and tnl_backers associated with a dpif_backer. For any ofports whose dst port has changed, we should change their odp_port to the appropriate tnl_backer, or create it if necessary. Once done, we can delete any tnl_backers which are no longer used by any ofports. Hopefully that is all clear. Let me know if you think the strategy won't work, or could be enhanced in some way. Thanks again for volunteering to have a look at this. Ethan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
