Liran Liss wrote: > S.B reading your replies would be much easier if you use strict bottom posting
>> For a long time we've assumed that the create_ah verb can't sleep, >> so where are you going to do neighbor discovery? > re [...] implementation, there is no inherent issue that prevents create_ah() > from sleeping: > - Change a few spinlocks to mutexes in the cma (which sleeps a lot anyway > because is > modifies QP states) > - Trivial for user-space calls... Documentation/infiniband/core_locking.txt states that "The corresponding functions exported to upper level protocol consumers: ... ib_create_ah ... are therefore safe to call from any context." Which is in turn assumed by bunch of components in the kernel IB stack (look for ib_create_ah calls under drivers/infiniband/core/). The examples you brought here, don't cover them. This way or another, I don't see any reason to break that convension just for the sake of this aspect of the iboe implementation, simply, code with this assumption at hand. Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
