On Mon, Aug 25, 2014 at 1:03 PM, Doug Ledford <dledf...@redhat.com> wrote: > >> On Aug 25, 2014, at 2:51 PM, Wendy Cheng <s.wendy.ch...@gmail.com> wrote: >> >> Is it really possible for ib_sa_join_multicast() to >> return *after* its callback (ipoib_mcast_sendonly_join_complete and >> ipoib_mcast_join_complete) ? > > Yes. They are both on work queues and ib_sa_join_multicast simply fires off > another workqueue task. The scheduler is free to start that task instantly > if the workqueue isn't busy, and it often does (although not necessarily on > the same CPU). Then it is a race to see who finishes first. >
Ok, thanks for the explanation. I also googled and found the original patch where the IPOIB_MCAST_JOIN_STARTED was added. This patch now makes sense. Acked-by: Wendy Cheng <wendy.ch...@intel.com> On the other hand, I'm still puzzled why ib_sa_join_multicast() can't be a blocking call (i.e. wait until callback is executed) - why would IPOIB pay the price to work around these nasty issues ? But I guess that is off-topic too much .. BTW, thanks for the work. Our users will be doing if-up-down a lot for power management, patches like these help ! -- Wendy -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
