[ovs-dev] [PATCH 2/2] datapath: Restructure vxlan tunneling.

Pravin Shelar pshelar at nicira.com
Tue Jul 2 19:46:38 UTC 2013


On Tue, Jul 2, 2013 at 12:13 AM, Rajahalme, Jarno (NSN - FI/Espoo)
<jarno.rajahalme at nsn.com> wrote:
>
> On Jul 2, 2013, at 1:28 , ext Pravin B Shelar wrote:
>
>> diff --git a/datapath/linux/compat/include/net/vxlan.h b/datapath/linux/compat/include/net/vxlan.h
>> new file mode 100644
>> index 0000000..76e0ddb
>> --- /dev/null
>> +++ b/datapath/linux/compat/include/net/vxlan.h
>> @@ -0,0 +1,43 @@
>> +#ifndef __NET_VXLAN_WRAPPER_H
>> +#define __NET_VXLAN_WRAPPER_H  1
>> +
>> +#include <linux/skbuff.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/udp.h>
>> +
>> +/* per UDP socket information */
>> +struct vxlan_sock {
>> +     struct hlist_node hlist;
>> +     struct rcu_head   rcu;
>> +     struct socket     *sock;
>> +     struct list_head  handler_list;
>> +};
>> +
>> +struct vxlan_handler;
>> +typedef int (vxlan_rcv_t)(struct vxlan_handler *vh, struct sk_buff *skb, __be32 key);
>> +
>> +struct vxlan_handler {
>> +     vxlan_rcv_t       *rcv;
>> +     struct list_head   node;
>> +     void              *data;
>> +     struct vxlan_sock *vs;
>> +     atomic_t           refcnt;
>> +     struct rcu_head    rcu;
>> +     struct work_struct del_work;
>> +     int                priority;
>> +};
>> +
>> +void vxlan_handler_put(struct vxlan_handler *vh);
>> +
>> +struct vxlan_handler *vxlan_handler_add(struct net *net,
>> +                                     __be16 portno, vxlan_rcv_t *rcv,
>> +                                     void *data, int priority);
>> +
>> +int vxlan_xmit_skb(struct net *net, struct vxlan_handler *vh,
>> +                struct rtable *rt, struct sk_buff *skb,
>> +                __be32 src, __be32 dst, __u8 tos, __u8 ttl, __be16 df,
>> +                __be16 src_port, __be16 dst_port, __be32 vni);
>> +
>> +__be16 vxlan_src_port(__u16 port_min, __u16 port_max, struct sk_buff *skb);
>> +
>> +#endif
>
> I may sound like a broken record here, but is there a reason to keep all of the above somehow vxlan specific? It seems to me these same facilities could be used for other UDP-based tunneling protocols as well. I get that this is compat code, but you also said that the upstream code is not yet there either, so maybe there is a chance to reconsider this now? Or is it better to refactor the code when more UDP-based tunneling protocols are upstreamed?
>
I agree this compat code is related more to UDP than vxlan. But there
is only one UDP based tunnel in kernel. Therefore I do not want to
make any changes to upstream vxlan patches at this point.
We can still keep refactored code in ovs-tree but that will diverge
tunneling code from upstream code which is not good from maintenance
point of view.



More information about the dev mailing list