WDK writes:
The Storport driver supports an I/O model tailored specifically for high-performance buses. This I/O model allows miniport drivers to operate in full-duplex mode, which means that a miniport driver can add new requests to its queue even while it is in the process of completing others. Moreover, in full-duplex mode, the miniport driver does not have to synchronize the execution of its StartIo and interrupt service routines. This can lead to significant performance enhancements. …
Now I want to understand 2 things:
1.It seems that in scsi miniport model, new SRB commands will not come unless an existed SRB is completed. Am I right?
2.In stor miniport model, if StartIo and interrupt service routines are writing the same variable, should they be synchronized?
Thank you!
> 1.It seems that in scsi miniport model, new SRB commands will not come unless
an existed SRB is completed. Am I right?
Only if you will not call ScsiPortNotification(Next(Lu)Request).
Such a call allows delivery of the next SRB even if the previous was not
completed yet.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Comments Inline …
imzoran@163.com wrote: WDK writes:
The Storport driver supports an I/O model tailored specifically for high-performance buses. This I/O model allows miniport drivers to operate in full-duplex mode, which means that a miniport driver can add new requests to its queue even while it is in the process of completing others. Moreover, in full-duplex mode, the miniport driver does not have to synchronize the execution of its StartIo and interrupt service routines. This can lead to significant performance enhancements. …
Now I want to understand 2 things:
1.It seems that in scsi miniport model, new SRB commands will not come unless an existed SRB is completed. Am I right?
No that is not the case. Check the documentation for HwScsiStartIo for the same.
2.In stor miniport model, if StartIo and interrupt service routines are writing the same variable, should they be synchronized?
Yes they need to synchronize for obvious reasons. StorPortSynchronizeAccess is the corresponding API.
Thank you!
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Forgot the famous last words? Access your message archive online. Click here.
Comments inline.
On Jan 25, 2008 6:34 AM, wrote:
> WDK writes:
> The Storport driver supports an I/O model tailored specifically for
> high-performance buses. This I/O model allows miniport drivers to operate in
> full-duplex mode, which means that a miniport driver can add new requests to
> its queue even while it is in the process of completing others. Moreover, in
> full-duplex mode, the miniport driver does not have to synchronize the
> execution of its StartIo and interrupt service routines. This can lead to
> significant performance enhancements. …
> ==========================================
> Now I want to understand 2 things:
> 1.It seems that in scsi miniport model, new SRB commands will not come
> unless an existed SRB is completed. Am I right?
That depends on what you mean by ‘an existed SRB is completed’, but I think
the answer is ‘no you are wrong’. ScsiStartIo is called with the adapter
spinlock held, serializing the call to ScsiStartIo from all other miniport
entry routines including your ISR. However you do not have to complete the
SRB to get another SRB, you merely have to exit ScsiStartIo having sent the
appropriateScsiPortNotifications back to ScsiPort (NextRequest,
NextLuRequest, or ScsiPortCompleteRequest).
2.In stor miniport model, if StartIo and interrupt service routines are
writing the same variable, should they be synchronized?
Thank you!
Your ISR and StorStartIo are synchronized while your StorBuildIo routine is
unsynchronized. The only real difference in the standard storport model from
the standard scsiport model is the StorBuildIo routine. Note however that
storport is introducing a third model to storport, the virtual miniport
driver model, which removes all implicit synchronization from the miniport
entry routines. This model is sort of documented in the WDK 6001.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
Now I agree that ScsiPortNotification(Next(Lu)Request) can notify system to send another SRB even when scsi miniport doesn’t complete its SRB’s.
But as for my “synchronization” problem, dear pawan rathi think I should use "StorPortSynchronizeAccess ". And dear Mark Roddy think no need to synchronize. Now I notice that WDK writes:
HwStorInterrupt:
The port driver calls the HwStorInterrupt routine at DIRQL after acquiring the Interrupt spinlock.
HwStorStartIo:
The port driver calls the HwStorStartIo routine at DISPATCH IRQL after acquiring the StartIo spinlock.
So how to explain they run at different IRQL levels? And spin lock could just synchronize dispatch-level routines.
The documentatio for storport is almost non-existent. Look at the I2o sample
in the WDK and see what it does. As far as I know startio and isr are run
with the adapter spinlock held at DIRQL - the same as scsiport. The
difference is BuildIo, which runs without the adapter spinlock held.
There are several winhec ppt presentations on writing storport drivers. They
aren’t terribly informative either, but they are better than the docs.
On Jan 27, 2008 10:37 PM, wrote:
> Now I agree that ScsiPortNotification(Next(Lu)Request) can notify system
> to send another SRB even when scsi miniport doesn’t complete its SRB’s.
> But as for my “synchronization” problem, dear pawan rathi think I should
> use "StorPortSynchronizeAccess ". And dear Mark Roddy think no need to
> synchronize. Now I notice that WDK writes:
> =============================
> HwStorInterrupt:
> The port driver calls the HwStorInterrupt routine at DIRQL after acquiring
> the Interrupt spinlock.
> HwStorStartIo:
> The port driver calls the HwStorStartIo routine at DISPATCH IRQL after
> acquiring the StartIo spinlock.
> =========================================
> So how to explain they run at different IRQL levels? And spin lock could
> just synchronize dispatch-level routines.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
WDK says:
DDK:
StorPortSynchronizeAccess:
Miniport drivers that operate in full-duplex mode, and that access information that is shared between their HwStartIo routine and interrupt-service routine, must use this routine to access the shared data in a synchronized manner.
The miniport driver passes a callback routine to StorPortSynchronizeAccess, and StorPortSynchronizeAccess calls it after guaranteeing exclusive access to sensitive data structures. The miniport driver’s callback routine must conform to the following prototype:
typedef
BOOLEAN
(* PSTOR_SYNCHRONIZED_ACCESS) (
IN PVOID HwDeviceExtension,
IN PVOID Context
);
where HwDeviceExtension is a pointer to the hardware device extension, and Context is just a pointer to the same context information that the caller supplied when calling StorPortSynchronizeAccess.
For more information, see Synchronized Access within Unsynchronized Miniport Driver Routines.
So now I think WDK itself has a contradiction.