Hi Mike, these is my second stab at the LU Reset handling update. The first patch implements the 'iscsi_check_tmf_restrictions' function, which allows us to filter out individual PDUs which should not be send.
The other patches are merely for improving LU Reset handling when 'fast_abort' is not set. In this case we should be sending all outstanding data-out PDUs to the target. However, with the current list traversal of while(!list_empty()) for the 'requeue' list we will break out on the first PDU for which tmf restriction check triggers. This will cause all other PDUs in the list not to be checked. So the first patch changes this to a 'normal' list traversal with 'list_for_each', which will process all PDUs. The second patch just sets the 'FINAL' bit for Data-out PDUs to terminate the transfer. And the third patch is flushing the workqueue _before_ the SUSPEND bit is set; otherwise iscsi_data_xmit() will be short-circuited by the SUSPEND-bit set, causing any data still queued not to be send. One thing I'm not quite sure yet: What are the contents of the 'requeue' list? Will that only be 'DATA-Out' PDUs? If so, then the last patch should be irrelevant as the 'requeue' list will be flushed anyway. If not, then the first and the third patch should be modified. The first should filter out Data-Out PDUs, but in realiter it just checks which queue is being used. So if the 'requeue' list contains non-Data-Out PDUs this check is clearly bogus. Similar goes for the third patch; the FINAL bit really makes sense only for Data-Out PDUs to be set; for normal SCSI cmd PDUs the FINAL bit has a different meaning and will induce a protocol error. As for the 'incomplete PDU' handling; we might be able to catch this by updating the second patch. Instead of breaking out of the loop we can just continue when an error occurred; this way we make sure that we're processing all outstanding PDUs. Those which failed will get processed by the next call to data_xmit(); assuming it was a transient error we should be able to process them. Of course, no guarantees there. The proper way would be to check the possible return codes and only break out on the non-retryable ones only, but continue for others. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
