[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