David Somayajulu wrote:
Why does your LLD need to reach up into the block layer to find an i/o
?
Block layer tagging was the gating item in the previous submission.
Going over the conversation on the linux-scsi reflector on STEX driver
in this aspect, led us to believe that there should not be any driver
level book-keeping of outstanding commands to the HBA. This was the
reason for creating scsi_host_find_tag() in scsi_tcq.h (in the patch
titled [RFC] [PATCH] helper function for retrieving scsi_cmd given
hostbased block layer tag)
http://marc.theaimsgroup.com/?l=linux-scsi&m=115871027627964&w=2
James, would you mind letting us know if block-layer tagging in your
opinion simply meant using the scsi_cmd->request->tag and let the driver
do the book-keeping of out-standing commands to HBA (like stex driver)
or is it along the lines we have implemented.
Well, in general, I've been working on stuff that has little use for the
tags, so they aren't that meaningful. I can certainly see some implementations
that can benefit.
But, on a newish transport like iSCSI, I'm surprised. There's lots of
house-keeping that has to be done with resets and task management that makes
me believe it's better/easier with local structures. I also know that I like
to double-check my hardware (based on local structure) rather than blindly
trusting job handles. I also believe there will be locking issues or data
structures in flight issues between the block layer and LLDD that will
be ugly.
I wanted some justification. The new block layer function hasn't been needed
in the past and I thought it a rather odd thing to add.
-- james
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
