[ovs-dev] [PATCH 3/3] ofproto-dpif-xlate: Implement RCU locking in ofproto-dpif-xlate.

Alex Wang alexw at nicira.com
Fri May 9 18:48:01 UTC 2014


Great to see this series.

Based on the offline discussion with Ryan, we think it is not ideal to
enforce the
double-standard that xlate module cannot take reference to netdev while
other
modules (e.g. bfd/cfm) must.  This makes the code more complicated.

The root cause of this double-standard is the need to guarantee that netdev
shash
does not contains the netdev when it is certain to be removed.  Currently,
the rcu_postponed
xport deletion may cause the netdev still in the shash and prevent the
creation of
new netdev with same name

One idea is to move the "removal of netdev from shash" logic into a
separate function.
And this function should be called whenever we are sure the netdev will be
removed (hope
there are not too many places and it is not invovled)

We will discuss this further, and update the thread with the direction to
go.



+static void
> +xlate_xport_copy(struct xbridge *xbridge, struct xbundle *xbundle,
> +                 struct xport *xport)
> +{
> +    struct skb_priority_to_dscp *pdscp, *new_pdscp;
> +    struct xport *new_xport = xzalloc(sizeof *xport);
> +    new_xport->ofport = xport->ofport;
> +    new_xport->ofp_port = xport->ofp_port;
> +    new_xport->xbridge = xbridge;
> +    xlate_xport_init(new_xport);
> +
> +    xlate_xport_set(new_xport, xport->odp_port, xport->cfm, xport->bfd,
> +                    xport->stp_port_no, xport->config, xport->state,
> +                    xport->is_tunnel, xport->may_enable);
> +
> +    /* Note that RCU read threads do not take a reference to netdev since
> this
> +     * blocks creation of netdevs with the same name after deletion or
> type
> +     * modification of the netdev */
> +    new_xport->netdev = xport->netdev;
> +
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140509/ca1e239c/attachment-0005.html>


More information about the dev mailing list