RE: [PATCH RFC] IB/iser: add task reference counter for tx commands

[Kashyap Desai <kashyap.desai@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

>
> Hi Kashyap Desai,
>
> Unfortunately, there is a wider problem in iser that we do the local
> invalidation if any, after we complete the iscsi task.
> So the right solution is to do the logic we have in NVMe/RDMA that checks
> if
> remote invalidation happened and if not, it does local invalidation.
> And the task is released after getting the send_completion and
> local_invalidation/remote invalidation.

Hi Max ,

I noticed the same. Agree that this RFC is not close to actual solution.
Final solution require major lift in iSER instead of just adding refcount in
couple of places.
In case of NVME every ib_post_send is posted with IB_SEND_SIGNALED and
nvme_rdma_send_done does the better job of handling out of order TX and RX
completion.
nvme_rdma_end_request() can be called either nvme_rdma_process_nvme_rsp,
nvme_rdma_send_done OR nvme_rdma_inv_rkey_done.
Similar concept is what we need in iSER side as well. Right ? Currently iSER
stack is freeing scsi request only from iser_task_rsp context.

>
> There is some infrastructure work needed to be done there.

I would like to contribute if you want me to test, review and/or co develop
the changes.


>
> Sagi,
>
> Please remind me few things regarding the iSCSI bidir cmds.
>
> In case of bidir IO cmd, if we need to use a reg_mr for it - I see a
> potential
> problem there.
> Is this scenario possible ?
>
> I'm asking because if it is possible, so what happens in remote
> invalidation ?
> what key is invalidated ? the read_key or the write_key ?
> in ib_isert there is a priority to the read_key (is it by the spec ?).
> We don't consider this in the iser recv completion and the remote
> invalidation
> checker logic.
> If it's not possible we should re-design few components in the code and
> fix the
> issue that we do local_invalidation of cmd N during the send of cmd N + 1.
>
> Cheers,
> -Max.
>

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4212 bytes --]