Complete Request in scsi miniport w/o timercall

NTDEV
1

Sorry for talking on this issue again…

With Anton’s help, I successfully completed the request without timercall.
However, I didn’t get the great performance as expected. As I can see from
the log, my workitem working on reading and writing will be switched out
about every 15ms which takes a lot of time. Is there anyway for the workitem
to run without interrupt, or is it surely a result of some poor programming?
The timercall is definitely removed, and there is no system thread used in
the miniport driver.

FYI, the StartIo routine in the miniport driver did the following steps:
if the psrb is vendor-specific, finish the original srb stored in
databuffer field and itself, then call
ScsiPortNotification(NextLuRequest…)
if not, call IoQueueWorkItem to process the srb, and build a new srb with
the completing srb in databuffer field, then call
ScsiPortNotification(NextLuRequest…)

Also, It will be the same if I use a working thread instead of work item.

Thanks for any reply.

Paul

Express yourself instantly with MSN Messenger! Download today - it’s FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2

One other trick, but still imposes somewhat of a delay, is to send another
request to the miniport to get the context right. Then you can complete the
request. The issue is well documented on this list and searching the
archives may help you.

Jamey

----- Original Message -----
From: “paul chen”
To: “Windows System Software Devs Interest List”
Sent: Friday, May 20, 2005 8:48 AM
Subject: [ntdev] Complete Request in scsi miniport w/o timercall

> Sorry for talking on this issue again…
>
> With Anton’s help, I successfully completed the request without timercall.
> However, I didn’t get the great performance as expected. As I can see
> from the log, my workitem working on reading and writing will be switched
> out about every 15ms which takes a lot of time. Is there anyway for the
> workitem to run without interrupt, or is it surely a result of some poor
> programming? The timercall is definitely removed, and there is no system
> thread used in the miniport driver.
>
> FYI, the StartIo routine in the miniport driver did the following steps:
> if the psrb is vendor-specific, finish the original srb stored in
> databuffer field and itself, then call
> ScsiPortNotification(NextLuRequest…)
> if not, call IoQueueWorkItem to process the srb, and build a new srb
> with the completing srb in databuffer field, then call
> ScsiPortNotification(NextLuRequest…)
>
> Also, It will be the same if I use a working thread instead of work
> item.
>
> Thanks for any reply.
>
> Paul
>
> _______________________________________________________
> Express yourself instantly with MSN Messenger! Download today - it’s FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@rocketdivision.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> NOD32 1.1100 (20050518) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>

3

>One other trick, but still imposes somewhat of a delay, is to send another

request to the miniport to get the context right. Then you can complete the

request. The issue is well documented on this list and searching the
archives may help you.

This sort of works. The problem with it is if you get an error on one of the
scsi devices, future requests across all targets handled by the minport may
become serialized. What happens then is the request you send to get things
into the right context is queued, and you end up needing a timer to process
the completion for the original request anyway. A while ago, this was the
case even if your miniport reported multiple busses and you sent requests on
a second bus to get things into a context to complete srb’s on the first
bus. I never understood why an error on bus 1 should cause bus 2 to become
serialized, but it does.

  • Jan
4

No matter what you do you will run into that 10 millisecond quantum, and you
will never achieve the same speed as a native driver. Even my “cheat” of
acquiring the SCSIPORT PDO, creating my own FDO, and registering my own DPC
was doomed to fail as Jan states. My results were promising but I never did
extensive testing on it, and abandoned it for VSPORT.

Your best bet is a third party port driver. With Storagecraft no longer in
the fray you may have to write your own.

Gary

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of paul chen
Sent: Friday, May 20, 2005 10:49 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Complete Request in scsi miniport w/o timercall

Sorry for talking on this issue again…

With Anton’s help, I successfully completed the request without timercall.
However, I didn’t get the great performance as expected. As I can see from
the log, my workitem working on reading and writing will be switched out
about every 15ms which takes a lot of time. Is there anyway for the workitem

to run without interrupt, or is it surely a result of some poor programming?

The timercall is definitely removed, and there is no system thread used in

the miniport driver.

FYI, the StartIo routine in the miniport driver did the following steps:
if the psrb is vendor-specific, finish the original srb stored in
databuffer field and itself, then call
ScsiPortNotification(NextLuRequest…)
if not, call IoQueueWorkItem to process the srb, and build a new srb with

the completing srb in databuffer field, then call
ScsiPortNotification(NextLuRequest…)

Also, It will be the same if I use a working thread instead of work item.

Thanks for any reply.

Paul

Express yourself instantly with MSN Messenger! Download today - it’s FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: glittle@mn.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________ NOD32 1.1103 (20050520) Information __________

This message was checked by NOD32 antivirus system.
http://www.nod32.com