[ovs-dev] VXLAN ports not working with latest master

Ethan Jackson 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.

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
>



More information about the dev mailing list