On 12/7/2016 3:04 AM, Bart Van Assche wrote:
On 12/06/2016 02:01 AM, Max Gurtovoy wrote:
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 separate 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.
Hello Max,
Do you agree with the approach of the attached two patches?
Thanks,
Bart.
Hi Bart,
thanks for the patches.
they will work in case of srp (the only user for DIRECT approach in the
ULP's), but don't you think it's a hard requirment for the caller to
ensure that no ib_poll_cq can be called during ib_set_cq_poll_context ?
There was some thought in the past to share cq's among ULP's that is
currently on hold (in this approach we can't be sure other context don't
call ib_poll_cq). In other hand we can avoid sharing DIRECT cq's.
Anyway, I thought of passing "struct ib_drain_cqe" as an arg to drain
function from ULP and wait for completion (with tmo) in the ULP level,
after direct ib_process_cq_direct.
I don't have an implementation yet, but I hope I explained my idea.
Thanks,
Max.
--
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
