On Mon, Aug 25, 2014 at 1:03 PM, Doug Ledford <dledford@xxxxxxxxxx> wrote: > >> On Aug 25, 2014, at 2:51 PM, Wendy Cheng <s.wendy.cheng@xxxxxxxxx> 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.cheng@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
