Maxim
Wed Oct 18 14:52:31 CDT 2006
The good idea is for the app/upper driver to remember the submit order of
the IRPs. The app can do this by wrapping OVERLAPPED with a larger structure
(with submit order fields - counter or offset - just below OVERLAPPED), and the
driver - via completion context.
The order of data chunks will match the submit order of the IRPs. The
_completion_ order of IRPs is arbitrary and relying on it is a very bad idea.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:%23QOcc1m8GHA.2268@TK2MSFTNGP05.phx.gbl...
> You don't even need to split input IRPs to several URBs.
>
> Have your application send several overlapped IOCTL requests each suitable
> for a single URB. Build an URB and send it down with the current IRP as an
> IOCTL_INTERNAL_SUBMIT_URB. A completion routine should free the URB. The
> driver becomes even simple, thus more stable.
>
>
> "fredsky" <hardware.evs@gmail.com> wrote in message
> news:1161073738.964751.221010@m7g2000cwm.googlegroups.com...
> For our design we use 512 KB URB block and we use Overlapped IO to have
> always 3 pending IRP. However we have found that splicing one IRP into
> multiples concurrent URBS become incredibly difficult to manage if the
> hardware sends 0 length buffers because as this is a completion case we
> must complete the main IRP. The question is what are we supposed to do
> with remaining URBS sent down to USB Host Driver ?? Because these URBs
> are associated with main IRP buffer I believe I must complete them all,
> but it's not so easy. Add the fact that next URB may have already
> received some new data, we end with an IRP that is filled with two
> different block of data.
>
> So by reading (or writing) large block of data but always on at the
> time we still have good performance (we only need to submit one URB to
> USB Host Driver after it has transferred 512 KB, so the penalty is
> negligible) ans our driver stay simple (and stable by definition).
>
>
> So if you need to transfer say 2 MB by IRP the whole schema would be :
>
> - Send IRP to your driver
> - Send 1 URB with 512 KB transfer size
> -> In Completion routine, test that you have transferred 512KB data
> (otherwise it's a completion condition , ie short packet). If so, then
> launch another URB, and so on until either you have transfered your
> whole buffer or you have received a short packet condition.
> - Then complete main IRP and dequeue another IRP (if any)
>
> Hope this helps,
> Fred.
>
>
>
> Thomas Schimming a écrit :
>
> > "Tim Roberts" wrote:
> >
> > > "fat_boy" <zzebowa@hotmail.com> wrote:
> > > >
> > > >Thomas Schimming wrote:
> > > >> Sorry to be a bit ignorant here. Do you mean that I can just send
> > > >> down two
> > > >> URBs for half the size and the second one catches the second half of
> > > >> my data
> > > >> block?
> > > >
> > > >Yes. You can break the data down into what ever size you like. We
> > > >found 1k to be optimal on XP. Any larger write and the USB system
> > > >would eventually stall. At 64 bytes, throughput was abysmal.
> > >
> > > This also depends on your hardware. If your hardware is able send data
> > > in
> > > a stream, and transfer as much as is available, then you do have this
> > > flexibility. Some hardware is pickier, and requires buffers of a
> > > certain
> > > size for correct operation.
> > > --
> > > - Tim Roberts, timr@probo.com
> > > Providenza & Boekelheide, Inc.
> > >
> >
> > In my case I have "separate" bulk transfers of a certain size (>1MB). As
> > far
> > as I understand the docs, there is no notion in the protocol to delimit
> > such
> > transfers other than the fact that at the end of such a transfer there is
> > a
> > NAK instead of more data?!
> >
> > Currently (on XP), by using a large bulk transfer with the "right"
> > blocklength, I am able to synchronize to the transfers of the device
> > (essentially I need to be able to catch the starts/ends right).
> >
> > So I'm still not clear about how I would detect these starts/ends with say
> > 1k blocked bulk transfers. I realize that this is probably all due to poor
> > design of the USB end of the device, but I don't have the option to work
> > on
> > that side of the fence.
> >
> > Also, how many 1k URBs would you recommend to have pending in order to
> > avoid
> > missing any data? What about thread priority of the "data loop"?
> >
> > Thanks for any thoughts.
>
>