[ovs-dev] VXLAN ports not working with latest master
ethan at nicira.com
Wed Feb 6 18:57:35 UTC 2013
> 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.
>> 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.
More information about the dev