On Feb 4, 2013, at 3:50 PM, Ethan Jackson <et...@nicira.com> wrote: >> 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. > Just getting to this in detail today.
> 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. > I see an issue right now. It looks like netdev_vport_get_dpif_port() currently just returns a const char * by returning a pointer to the dpif_port pointer on vport_class. Modifying this behavior to return a dynamic name here means we need to allocate a char * pointer here and modify the callers to free the memory via a helper function. Any other ideas? > 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. > This part seems reasonable and makes sense. > 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
