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

Kyle Mestery (kmestery) kmestery at cisco.com
Wed Feb 6 19:01:10 UTC 2013

On Feb 6, 2013, at 12:57 PM, Ethan Jackson <ethan at nicira.com>
>> 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.


> 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