Nono.. we're confused here. What I'm describing here is a three-stage transaction, with the middle stage being a scatter-gather stage -- that is, the "data" phase involves trying to get data in/out of multiple non-contiguous buffers.
So, I'm not talking about 3 URBs... I'm talking about 12. One command, 10 data, and 1 status. The problem here is that there is a semantic difference between the way command/data/status are queued together and the way the data segments are queued together, and we need a way to represent both. Command/data/status should be queued together so that a short packet does _not_ stop the next transaction. Data blocks need to be queued together so that a short packet _does_ stop a transaction. The problem is, for maximum effeciency, I want to be able to use _both_ types of queueing. I want scatter-gather as well as "unrelated URB" (for lack of a better term) queuing. Matt Dharm On Sun, Nov 25, 2001 at 05:54:47PM -0500, Johannes Erdfelt wrote: > On Sun, Nov 25, 2001, Matthew Dharm <[EMAIL PROTECTED]> wrote: > > On Sun, Nov 25, 2001 at 12:43:22PM -0800, David Brownell wrote: > > > Actually my current thought is that the bulk queuing ought > > > to have those exact semantics ... and it's such "fault" handling > > > that's exactly where I mentioned (privately) that I see the > > > problems coming, similarly on the write side and in terms > > > of cancellation. I don't think our HCs do that "right", either > > > in the spec sense (see next) or the pragmatic "code does > > > reasonable things" sense (consider your scenario). > > > > See, then I can compose a counter-scenario. > > > > Consider the following: usb-storage wants to send 3 "transactions" to a > > device. A bulk-out command, a bulk-in/out for data, and a bulk-in for > > status. Can I queue all these up? > > Yes, using ->next. > > > If the short-transfer on data causes all URBs to stop, then the status is > > never transferred. > > Umm, that's not what would happen. > > Short packet is not an error if SPD is enabled. It would then progress > to the next transfer. > > If an error does occur, the ->next processing is not done. > > > If the short-transfer on data does not cause the URBs to stop, then the > > status information winds up in the user buffer. > > Yes, obviously bad situation. > > > If, however, the HCD understood that the data was a single 'transfer', the > > short-packet would properly retire just the data phase and we could > > progress to the status phase. > > It already does do this correctly with ->next. > > > This is why I want the HCD to understand scatter-gather. It's the only way > > that I can get the entire data phase treated as a single transfer, which is > > how the model wants to look at it. > > What you're describing here is not what I would traditionally call > scatter-gather. > > I've always seen scatter-gather split up one logical block of data into > multiple physical blocks of data. Like 1 block for an IP header, 1 block > for a TCP header and 1 block for the data. It would then send all 3 > blocks together as one logical block. > > You seem to be describing something different with 3 different phases > which go to different endpoints (bulk in being different than bulk out). > > JE > > > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Hi. I have my back hairs caught in my computer fan. -- Customer User Friendly, 8/20/1998
msg02702/pgp00000.pgp
Description: PGP signature
