erezz at voltaire.com wrote on Wed, 15 Aug 2007 12:26 +0300: > At first, I thought that this will be easy to fix - just move the va & > stag from the conn object to the task object. However, when ep_read > (iscsi_iser_read in iSER's case) is called, the task isn't allocated > yet. iSER must save the data from the received iSER header in some task > object (e.g. iser_task). You could add a new transport call .ep_task_init and call that near the iscsi_alloc_task() in iscsi_scsi_cmd_rx_start(). It gets the newly allocated struct iscsi_task. The TCP case would be a noop. The RDMA case would take the cached rem_stag values from the connection structure and stick them in the task struct. This is all done synchronously while working on the single received PDU so should be safe. You only need to call ->ep_task_init(task) in the SCSI command case, not TM functions or other places that will not do RDMA data transfers. > The solution that I see for that is: > > * When iSER detects that a new cmd was received, it allocates an > iSER task (iser_task). iser_task will contain the following data: > o read va & stag > o write va & stag > o itt > > The new iser_task will be stored (in a hash table according to its > itt?), and will be used later. > > * When the target calls ep_rdma_read/write, it will also send the > iscsi_task object (or itt, at least). iSER will extract the > iser_task (according to the itt) and use the va & stag. > * The iser_task will be released when iscsi_task is released. This would work but seems a bit more complex than necessary. It does have the advantage of keeping RDMA bits (va, stag) out of the generic iscsi task structure though. If somebody complains about adding another iscsi transport interface function just for RDMA. -- Pete |