thanks Bart.
I understand why the beacon/drain is needed but I'm wondering if it's
enough draining only the recv_q/send_q of the qp.
These are 2 seperate queues in the qp so receiving the beacon on the
recv_q, In theory doesn't ensure the all the send_q elements flushed.
Moreover if the cq is different for recv/send queues.
I can't prove it currently but I think I saw these happens when
developing iSER over FreeBSD (It was long time ago so it might have
happend because we posted stuff after posting the beacon).
In the current implementation we can't drain with IB_POLL_DIRECT ctx
(like srp send_cq) but we might think of implementation that can enable
it if needed.
On 12/5/2016 7:05 PM, Bart Van Assche wrote:
On 12/05/2016 06:43 AM, Max Gurtovoy wrote:
hi guys,
I've noticed that we use ib_drain_rq in teardown flow in ib_srp driver.
Trying to figure out why is this better than ib_drain_qp ?
BTW, the recv_cq != send_cq in srp so it's even better to use
ib_drain_qp, isn't it ?
I haven't encountered a bug in this area yet, but just trying to
understand if it's there.
Hello Max,
The description of a patch that was accepted upstream about two years
ago explains the purpose of the ib_drain_rq() call:
commit 7dad6b2e440d810273946b0e7092a8fe043c3b8a
Author: Bart Van Assche <bvanassche@xxxxxxx>
Date: Tue Oct 21 18:00:35 2014 +0200
IB/srp: Fix a race condition triggered by destroying a queue pair
At least LID reassignment can trigger a race condition in the SRP
initiator driver, namely the receive completion handler trying to
post a request on a QP during or after QP destruction and before
the CQ's have been destroyed. Avoid this race by modifying a QP
into the error state and by waiting until all receive completions
have been processed before destroying a QP.
Reported-by: Max Gurtuvoy <maxg@xxxxxxxxxxxx>
Signed-off-by: Bart Van Assche <bvanassche@xxxxxxx>
Reviewed-by: Sagi Grimberg <sagig@xxxxxxxxxxxx>
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
There is no risk that any send work will be posted while the ib_srp
driver destroys a QP.
Bart.
--
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
