Brian:
Thanks for your review. Responses are inline below.
- Manoj Kumar
On 6/4/2015 9:38 AM, Brian King wrote:
+
+ write_lock(&cfg->tmf_lock);
What is this lock protecting? The only thing it seems to be accomplishing is
making sure one thread isn't sending a TMF and another thread is sending
a normal I/O command at the exact same time, yet it looks like you still
allow a TMF to be sent and a normal I/O to be sent immediately after, before
receiving the TMF response.
Originally this section was waiting for the TMF response. I see that is
no longer the case. Will restore the original behavior, with adequate
locking.
+ afu->room = readq_be(&afu->host_map->cmd_room);
Looks like you now have an MMIO load as part of sending every command,
including commands coming from queuecommand. Won't that be a performance issue?
Is there any way to avoid this? Could you perhaps decrement afu->room
in this function and only re-read it from the AFU when the counter hits zero?
Good point. Will revise to avoid MMIO in this performance path.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
