Implications of setting MLX5_SINGLE_THREADED in 1 thread-per-qp multi-threaded app

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I am aware that I am misusing the semantics of MLX5_SINGLE_THREADED in
the example scenario below. But this question is for learning
purposes:

I have a multi-threaded application that uses 4 QPs in in 1 CTX. Each
QP has its own PD, MR and CQ and a dedicated thread that drives it.
Thread_i that drives QP_i will also poll CQ_i. So no locks are needed
on the QP (and the CQ for that matter). No locks are needed on the
uuars mapped to the QPs either since, with 4 QPs, they are still low
latency uuars. If I set MLX5_SINGLE_THREADED=1 in this case to run
this app, would it render incorrect behavior in terms of ringing the
doorbell?

My understanding of doorbell writes is not concrete yet and so, I'm
not sure if it would be correct behavior. For the rest of the locks,
since no threads are contending on a QP or a CQ, turning off the
locking mechanism with MLX5_SINGLE_THREADED=1 as a hack should be
okay.

Thanks,
Rohit Zambre
--
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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux