On 12/14/2011 11:53 PM, Sarah Sharp wrote:
Thanks for testing! Are these patches on top of the patches I sent out
a week ago? Or just on top of Greg's tree?
They are ontop of Greg's tree. I know that you sent a patch to fix the
same issue I did on my #1 patch. I remember that something did not work
out. It might be the thing for which I need #2. So if you want me to
rebase those two or redo something please let me know.
To deal with canceled commands (where we may have to kill some status urbs)
I've been thinking about a list within uas_dev_info which keeps track of
all status urbs and counts all commands which are queued. Once we start
removing commands which timed out we should make sure that the number of
commands which remain is the same as the number of status urbs which we
have. If we have more status urbs than commands then we kill some status
urbs. If it is the other way around then someone was too trigger happy.
That might work, but we'd have to synchronize the list manipulations
across status completions. That would get complex in the USB 3.0 case,
where we could (potentially, if the xHCI driver had multiple event ring
support and the host had MSI-X support) have two status completion
handlers running on different CPUs. One of the completion handlers
would have to spin, waiting on the other. So if we can avoid a list of
outstanding URBs, that would be better.
USB3.0. I see. On 3.0 we would have one status urb for each command so
it might end up in the command struct.
Matthew was just mentioning to me that it might be good to just have one
status URB per USB 2.0 UAS device, and just keep re-submitting it. USB
2.0 devices don't have streams, so there can't be multiple status URBs
being processed at the same time, so I think it would work. The only
Oh. That sounds great. I've been thinking how to avoid multiple
allocation/allocation of them.
difficulty I see is syncing the status completion with an abort of the
same command, but I think that could be done with an RCU reader lock in
the status completion. There shouldn't be any performance difference
between re-using one status URB or using a dedicated one in the
cmnd_info structure. Plus, we wouldn't have to allocate status URBs in
completion handlers if we just used one dedicated status URB.
yep. Sounds like a plan.
For USB 3.0 UAS, I think the status URB should stay in the cmnd_info
structure, since we know that when a status URB completes for a
particular stream ID, it is directly associated with that command, and
not a different command. So I'd like to address the sense URB failure
issue you tried to fix in the second patch, but I think we should go
about it in a different way.
Fine by me. You want me to redo #2 with one status urb/uas device or do
you do it yourself?
Sarah Sharp
Sebastian
--
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
