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

[Kyle Mestery (kmestery)]

On Feb 4, 2013, at 3:50 PM, Ethan Jackson <ethan at 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