Internal Queues and Start IO
Sushma
I am porting WDM SCSI port driver to KMDF. The WDM driver has startio
routine and maintains IRPs with internal queues.
For WDF version i am planning to create a default queue and forward it
to the read/write queue when required. Default queue and read/write
queue are both sequential queues. I am not sure if this queuing would
work out for me.
I have gone through KMDF serial sample for IRP queuing. I think i need
to go in similiar lines for managing queues for IRPs and startio
routine.
I am really stuck up in taking the right decision. Can any one let me
know if this queuing mechanism would help me to solve the problem.
Any help is much appreciated.
Thank You.
Regards,
Sushma
Don Burn
question is why are you doing this? Microsoft will no longer sign/support
monolithic SCSI port drivers, so moving this to a new technology makes
absolutely no sense.
You can use the Storport with a virtual device, and have the logic for the
driver in a KMDF driver called from the storport.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Sushma" <sushma...@gmail.com> wrote in message
news:0052ea83-0952-4919...@s50g2000hsb.googlegroups.com...
Sushma
Sorry for the confusion. I am only using SCSI port technology for my
storage driver. The driver i am writing is for supporting storage
cards like SD and MS. I have a PCI device which SD and MS functions. I
am implementing SCSIOP_READ and SCSIOP_WRITE commands for handling
read/write operations.
In this regard i need to handle queues.
Thank You.
Regards,
Sushma
Sushma
Can some one from MS reply to my query. I need it very urgently. Your
valuable suggestions will help me plan a perfect design for the
driver.
Thank You.
Regards,
Sushma
DeStefan
As far as i understood you just want to have a "decision" if you shall use a
queue or not?
For me this is the common way to do such things like you want to do.
So please explain your probleme a little more specifically.
What is your intention? Do you have a performance problem or what?
Are you intending to handle all IRPs via StartIo routine or do you want to
queue them just in read/write case and handle all other irps sequentially by
treating them on receiption?
At the moment you receive let's say a write request and a read request in
almost same time (meaning the write request is still not finished during
receipt of read),
then you will still stuck in your StartIo routine handling the write request
since startio is sequentially per se.
the only approach is making a thread that does the job for you.
On receipt of "write" you pass the IRP to the thread and deque the next IRP
in this case the "read"
After completing the write request you neet to complete the Irp in your
thread.
In the meanwhile you can dispatch the read request in your StartIo.
Maybe with another thread.
But in my opinion it is best practice if you have one single queue. where
you place your IRPs. And you delegate your tasks to several threads which
make the finalisation (IOCompleteRequest()).
I see no reason why you should use multiple queues. And if, then let's just
two: One for read/write, and another for other IRPs
Sushma
sequential.
So, as you have said if read and write irps arrive at almost same
time, then the default queue would receive the irps. I think i need to
maintain an internal queue (not default queue) which dequeues from
default queue and process the irp. In that way i would not miss any
irps.
The internal queue would be a simple linked list using
InitializeListHead, etc..
Do you think if this is the feasible approach to my problem? Can i
achieve the equivalent of WDM startio and internal queues in WDF.
Thank You.
Regards,
Sushma
Doron Holan [MSFT]
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sushma" <sushma...@gmail.com> wrote in message
news:25f08e31-1e28-4e67...@u36g2000pro.googlegroups.com...
DeStefan
> I think i need to maintain an internal queue (not default queue) which dequeues > from default queue and process the irp. In that way i would not miss any irps.
Since the queue is nothing else than a double or single linked list, a
driverqueue (also the default queue) has not a REAL limit meaning number of
queable objects. As long as there is enough NonPaged memory available you
will not miss any irp. this also regards the default queue. So this is
definetly not the aspect why you should use an internal queue!!! And if you
would run into memory problems due to a large amount of queue entries, you
can believe me, that you will get much more troubles than just missed irps ;-)
> Do you think if this is the feasible approach to my problem? Can i
> achieve the equivalent of WDM startio and internal queues in WDF.
Read the documentation of "WdfIoQueueStart()" here you can find the
information about the "KeInitializeDeviceQueue()" equivalent.
http://msdn.microsoft.com/en-us/library/aa491583.aspx with this link you
will get directly to the wdf documentation that covers your desired topic.
I cannot make the decision for you, but i experienced that the fastest
solutions are the simplest solutions. As i told you, you don't need to be
afraid that default queue will miss an irp. So it is better if you will use
the default instead a propreitary one, if you just want to copy the irp from
one queue to the other (which is not only timewasting but also senseless)
If you want to achieve "parallelness", meaning that you can handle multiple
irps same time, the only way is using multiple threads which do the job for
you and then complete the irps. Maybe for you it is more convenient that you
have two different queues (one for read, another for write). Then feel free,
to take another queue into your deviceobject.
I also would recommend that for all other irps (like ioctl calls, power and
pnp calls) you directly treat them in your dispatch callback routine and to
do not queueing them and dispatch them delayed in IoStart...
You know that in conext of StartIo you are in DISPATCH_LEVEL and not in
PASSIVE_LEVEL, which may be a disadvantage since you cannot use any paged
code or data, as well as synchronisation dispatchobjects like mutex and
events like you are used to do as in passive level.
Sushma
I think i got enough information to start with. One last question, As
i have said i would be using sequential queue. So, if two requests
happen to arrive at same time, the second request will not be
processed until the first one is completed.
So, reading and writing happening in parallel will not have any impact
if i use sequential queue. The request which arrive first will be
processed and then the next one. Is it correct?
Thank You.
Regards,
Sushma
DeStefan
> if i use sequential queue. The request which arrive first will be
> processed and then the next one. Is it correct?
Normal flow of irp's:
IRP comes into your dispatchroutine.
Here you make a decision: Will i treat the irp right now, or will i queue
the irp?
If you decide that you want to treat the irp right now, just do it. If it is
a quick algorithm behind the treatment->No problem at all
If you queue it, you will call IoStartPacket (sorry, i do not know the wdf
pendant).
This queues the irp or, if queue is empty already, will immediately call
your StartIo function. As you can see, the Interface is not locked already,
since you can still collect irp packets coming in.
You should also know, that it does not matter if this is a read/write or
ioctl call, the procedure is always the same, except the DispatchFunction is
a different.
As you see, there is no parellelness at all, but...
but there is no rule that says, you must complete one irp before you treat
the next irp, and this is the part that brings paralellness into the game.
let's say you have queued two irps (1 read and 1 write).
Your StartIo routine is being called. You dequeue the first irp (the read).
Now you start a helper thread and pass the irp to this thread. At this
moment the thread does the long term job. in the meanwhile you can continue
to dispatch the next irp (the write). Simply call IoStartNextPacket()
remember that the first one is still running on the other thread. You can
procede in the same manner like the read before.
Of course, you have to care about synchronisation topics. But as soon as the
threads are finished, you can complete the IRP within the thread, but this
does not bother your queue.
Another information:
I don't know if you are using overlapped mode. If not, i am using a good
trick in my drivers:
Just opening more than one instances to the interface (multiple file opens
to the driver, each for another thread), then any operation (read/write/ioctl
call) may concurrently exchange data with the driver without blocking (except
if i block on a dispatch object like mutex or semaphore is explicitly
demanded).
Even if i am not using the multithread technique i mentioned before!!!!
Therefore i never queue anything and always dispatch my irps right in the
dispatchroutine (without startio)
Don Burn
and since the OP is talking storage most storage system fire multiple
requests if at all possible,
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"DeStefan" <DeSt...@discussions.microsoft.com> wrote in message
news:838790F8-FA91-463F...@microsoft.com...
Maxim S. Shatskih
> pendant).
For pre-WDF code, the IoCsqXxx routines are the current queue implementation,
IoStartPacket is obsolete for 5 years or so.
> Your StartIo routine is being called. You dequeue the first irp (the read).
> Now you start a helper thread and pass the irp to this thread.
1. Starting a thread at IRP arrival is a bad idea, it is better to start it at
device object init or use IoQueueWorkItem which will start a thread for you.
2. There is no need in queue if you will use worker thread, just call
IoQueueWorkItem from the dispatch routine.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com