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

Jesse Gross jesse at nicira.com
Thu Jul 11 00:49:32 UTC 2013


On Mon, Jul 1, 2013 at 3:28 PM, Pravin B Shelar <pshelar at nicira.com> wrote:
> diff --git a/datapath/linux/compat/include/linux/skbuff.h b/datapath/linux/compat/include/linux/skbuff.h
> index d485b39..177fa23 100644
> --- a/datapath/linux/compat/include/linux/skbuff.h
> +++ b/datapath/linux/compat/include/linux/skbuff.h
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37)
> +extern void __skb_get_rxhash(struct sk_buff *skb);
> +static inline __u32 skb_get_rxhash(struct sk_buff *skb)
> +{
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,34)
> +       if (!skb->rxhash)
> +#endif
> +               __skb_get_rxhash(skb);
> +
> +       return skb->rxhash;
> +}
> +#endif

This will be satisfied with an L3 hash but I think we really want to
insist on an L4 hash to get decent entropy, which is also what new
kernels do.

> diff --git a/datapath/linux/compat/skbuff-openvswitch.c b/datapath/linux/compat/skbuff-openvswitch.c
> index 2707ef0..5aa1b4b 100644
> --- a/datapath/linux/compat/skbuff-openvswitch.c
> +++ b/datapath/linux/compat/skbuff-openvswitch.c

Should these functions be in flow_dissector.c?

> diff --git a/datapath/linux/compat/vxlan.c b/datapath/linux/compat/vxlan.c
> new file mode 100644
> index 0000000..21271f1
> --- /dev/null
> +++ b/datapath/linux/compat/vxlan.c
> +struct vxlan_handler *vxlan_handler_add(struct net *net,
> +                                       __be16 portno, vxlan_rcv_t *rcv,
> +                                       void *data, int priority)
> +{
> +       struct vxlan_net *vn;
> +       struct vxlan_sock *vs;
> +       struct vxlan_handler *vh;
> +       struct vxlan_handler *new;
> +       int err;
> +
> +       err = vxlan_init_module();
> +       if (err)
> +               return ERR_PTR(err);
> +
> +       vn = net_generic(net, vxlan_net_id);
> +       mutex_lock(&vn->sock_lock);
> +       /* Look to see if can reuse socket */
> +       vs = vxlan_find_port(net, portno);
> +       if (!vs) {
> +               vs = vxlan_socket_create(net, portno);
> +               if (IS_ERR(vs)) {
> +                       new = (void *) vs;
> +                       goto out;
> +               }
> +       }
> +
> +       /* Try existing vxlan hanlders for this socket. */
> +       list_for_each_entry(vh, &vs->handler_list, node) {
> +               if (vh->rcv == rcv) {
> +                       atomic_inc(&vh->refcnt);
> +                       new = vh;
> +                       goto out;
> +               }
> +       }

Why do we want to allow multiple of the same handler on a given port?
It seems like at the very least if we have two entries with the same
priority on the same port then we should reject the second one.
X-CudaMail-Whitelist-To: dev at openvswitch.org



More information about the dev mailing list