It appears this patch will be pushed, so I'll send out v3 of the xlate RCU locking patch.
Cheers, Ryan Wilson Member of Technical Staff [email protected] 3401 Hillview Avenue, Palo Alto, CA 650.427.1511 Office 916.588.7783 Mobile On May 15, 2014, at 11:16 AM, Ryan Wilson <[email protected]> wrote: > Here's my newest patch addressing this issue: > > http://permalink.gmane.org/gmane.network.openvswitch.devel/33292 > > Also, the second idea to resolve this issue which I discussed offline with > Ethan was to have the netdev struct have a pointer to its subclass (i.e. > netdev with name 'p0' has a pointer to its dummy subclass). Thus, when > switching types, we could use the RCU userspace API. > > However, this solution wasn't quite as simple as advertised as the > netdev_open function is used in many places with the following logic: open > the netdev with the following name 'p0' if it exists, otherwise create 'p0' > with this new type (netdev_open in netdev_get_in4_by_name is a good example > of this). Its likely that we would have to have 2 different netdev_open's > here, one which do the logic as explained in the previous sentence and one > which will add a type check if 'p0' exists and if it exists, create 'p0' with > the new type. In my opinion, this makes the code more complicated as there > are two versions of netdev_open or requires a deeper refactoring of the > netdev API. > > Anyways, let me know what your thoughts are on this and if this sounds good, > I'll resubmit my RCU locking patch corrected for this change. > > Ryan Wilson > Member of Technical Staff > [email protected] > 3401 Hillview Avenue, Palo Alto, CA > 650.427.1511 Office > 916.588.7783 Mobile > > On May 9, 2014, at 11:48 AM, Alex Wang <[email protected]> wrote: > >> 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; >> + >> > > _______________________________________________ > dev mailing list > [email protected] > https://urldefense.proofpoint.com/v1/url?u=http://openvswitch.org/mailman/listinfo/dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=TfBS78Vw3dzttvXidhbffg%3D%3D%0A&m=P1T73jzex2YeELYacL34l6YV0W0R7Az%2FuaXUJRqdLeU%3D%0A&s=b7ede33ff1bb51a1e1fb3ea1dde7198e62ecfd809db69847c27da4cd4b64bb56
_______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
