On Feb 6, 2013, at 12:57 PM, Ethan Jackson <et...@nicira.com> wrote: >> 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? > > These names need to be fairly short, so I think we can get away > without heap allocating them. I was thinking that we'd create a > statically allocated char array of length IFNAMESIZ, and just sprintf > the vxlan dpif port name into that. Have a look at > ofp_port_reason_to_string() for an example of what I was thinking. > That's exactly what I did actually, we're on the same page.
BTW: I've got things working now such that I can create VXLAN ports again. I just need to clean things up a bit and add add the code to handle tbl_backer management. With any luck I'll have some patches to send out today yet. Thanks, Kyle > Ethan > > > > >> >>> 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
