Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > Subject: [openib-general] Re: ipoib: outstanding patches > > OK, I've started reviewing and applying these. > > > ipoib_mc_list.patch > > Applied, except spin_lock_bh() followed by spin_lock_irqsave() looked > silly to me, so I changed it to spin_lock_irqsave() followed by spin_lock().
Thats fine too. > > ipoib_flush_wq_1.patch > > ipoib_flush_wq_2.patch > > Still trying to decide if I like this approach. Right now the ipoib > workqueue is only doing multicast stuff, so it's easier for me to see > what's going on. These patches lose that so I'm trying to see if > there's a better approach. > > > ipoib_mcast_send.patch > > Could we reuse the IPOIB_MCAST_RUN bit rather than adding a new bit? > It seems that we could kill mcast_mutex and replace uses with > priv->lock instead -- I don't see anything that sleeps inside mcast_mutex. I'll need to think about this. > > ipoib_all_neigh_issues_2.patch > > Could we do this without a linear search through a list of neighbours? > It seems this might become a scalability issue. We could have a list of distinct ops pointers. Would that be better? > > ipoib_multicast_leak.patch > > Why does this change only handle send-only multicast groups? Where > are other multicast groups getting freed now that misses send-only groups? Linux will clean other groups from mc_list so restart will kill them. -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
