> reading your replies would be much easier if you use strict > bottom posting
OK :) > > >> 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. > I understand this, but keeping ib_create_ah() callable from any context is not a goal by itself. I am looking for constructive ideas for supporting iboe without breaking Verbs/CQE/CM syntax. What do you propose?-- 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
