> > 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:
smime.p7s
Description: S/MIME Cryptographic Signature
