Hi all!
I’ve got a question on Win2K SCSI port driver functionality.
Port driver passes SRBs to miniport driver not in the same order
they come from disk class driver to port driver. It was investigated that
SRBs order depends on some fiels of IRP and SCSI_REQUEST_BLOCK structures.
Does anybody know for sure what logic of SRB requeuing is implemented
in SCSI port driver.
Thanks in advance.
port passes SRBs to the miniport in an arbitrary order. neither the
driver above (disk) nor the driver below (your miniport) should make any
assumptions about what order requests will be dispatched into the
miniport.
the logic for the queueing has changed in just about every release as we
try to increase scsiport’s performance. Win2k attempts to use a
modified Cscan algorithm for sorting the queue based on the QueueSortKey
field in the SRB but that’s not a guarantee.
if you have an upper level driver which needs to complete requests A, B
and C in that order then it must wait for A to complete before sending B
and again before sending C.
-p
-----Original Message-----
From: Shaggy Head [mailto:xxxxx@hotmail.com]
Sent: Friday, June 07, 2002 7:26 AM
To: NT Developers Interest List
Subject: [ntdev] SCSI port SRB queuing.
Hi all!
I’ve got a question on Win2K SCSI port driver functionality.
Port driver passes SRBs to miniport driver not in the same order
they come from disk class driver to port driver. It was investigated
that SRBs order depends on some fiels of IRP and SCSI_REQUEST_BLOCK
structures. Does anybody know for sure what logic of SRB requeuing is
implemented in SCSI port driver.
Thanks in advance.
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
> Does anybody know for sure what logic of SRB requeuing is
implemented
in SCSI port driver.
KexxxDeviceQueue with on-disk byte offset as a key.
Usual elevator seek.
Max
Peter,
thanks for your reply.
Does “…an arbitrary order…” of SRBs mean that SCSI commands order
isn’t of great importance below Disk Class driver? Can we shuffle IRPs
and SRBs arbitrarily in that case? How can this disordering affect the
data
stored at the target side?
Regards,
SH.
port passes SRBs to the miniport in an arbitrary order. neither the
driver above (disk) nor the driver below (your miniport) should make any
assumptions about what order requests will be dispatched into the
miniport.the logic for the queueing has changed in just about every release as we
try to increase scsiport’s performance. Win2k attempts to use a
modified Cscan algorithm for sorting the queue based on the QueueSortKey
field in the SRB but that’s not a guarantee.if you have an upper level driver which needs to complete requests A, B
and C in that order then it must wait for A to complete before sending B
and again before sending C.-p
-----Original Message-----
From: Shaggy Head [mailto:xxxxx@hotmail.com]=20
Sent: Friday, June 07, 2002 7:26 AM
To: NT Developers Interest List
Subject: [ntdev] SCSI port SRB queuing.Hi all!
I’ve got a question on Win2K SCSI port driver functionality.Port driver passes SRBs to miniport driver not in the same order
they come from disk class driver to port driver. It was investigated
that SRBs order depends on some fiels of IRP and SCSI_REQUEST_BLOCK
structures. Does anybody know for sure what logic of SRB requeuing is
implemented in SCSI port driver.Thanks in advance.
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
As Peter said, if there is an ordering required then it must be imposed
by the software modules above disk.sys, i.e. by the filesystems or
applications.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shaggy Head
Sent: Sunday, June 09, 2002 9:15 AM
To: NT Developers Interest List
Subject: [ntdev] RE: SCSI port SRB queuing.Peter,
thanks for your reply.Does “…an arbitrary order…” of SRBs mean that SCSI
commands order isn’t of great importance below Disk Class
driver? Can we shuffle IRPs and SRBs arbitrarily in that
case? How can this disordering affect the data stored at the
target side?Regards,
SH.> port passes SRBs to the miniport in an arbitrary order.
neither the
> driver above (disk) nor the driver below (your miniport)
should make
> any assumptions about what order requests will be
dispatched into the
> miniport.
>
> the logic for the queueing has changed in just about every
release as
> we try to increase scsiport’s performance. Win2k attempts to use a
> modified Cscan algorithm for sorting the queue based on the
> QueueSortKey field in the SRB but that’s not a guarantee.
>
> if you have an upper level driver which needs to complete
requests A,
> B and C in that order then it must wait for A to complete before
> sending B and again before sending C.
>
> -p
>
> -----Original Message-----
> From: Shaggy Head [mailto:xxxxx@hotmail.com]=20
> Sent: Friday, June 07, 2002 7:26 AM
> To: NT Developers Interest List
> Subject: [ntdev] SCSI port SRB queuing.
>
>
> Hi all!
> I’ve got a question on Win2K SCSI port driver functionality.
>
> Port driver passes SRBs to miniport driver not in the
same order
> they come from disk class driver to port driver. It was
investigated
> that SRBs order depends on some fiels of IRP and SCSI_REQUEST_BLOCK
> structures. Does anybody know for sure what logic of SRB
requeuing is
> implemented in SCSI port driver.
>
> Thanks in advance.
>
> —
> You are currently subscribed to ntdev as: xxxxx@microsoft.com To
> unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
%%email.unsub%%
> Does “…an arbitrary order…” of SRBs mean that SCSI commands
order
isn’t of great importance below Disk Class driver?
Surely.
and SRBs arbitrarily in that case? How can this disordering affect
the
data
stored at the target side?
For well-behaving SCSI target, it will not affect the data.
Max
>
> and SRBs arbitrarily in that case? How can this disordering affect
the
> data
> stored at the target side?For well-behaving SCSI target, it will not affect the data.
Max
If the target is a disk array or other shared SCSI device, or perhaps even if it is not,
even if the driver put the CDBs on the wire in order, and even if it specified
ORDERED TAGS on those CDBs, the initiator cannot depend on any ordering,
because the target may return a BUSY or QFULL on the first request,
but a request right behind it may get through.
The target is a tape drive, and you “know” you are not exceeding Qdepth, then
the order on the wire may be critical.
So the class driver has significant responibility for being well-behaved, not just the target.
-DH
As I understand QueueSortKey is a sort key 
for performance
increasing on initiator side. But DDK says that it “Specifies the
offset from the start of the media or zero, depending on the type of
the target device”.
What does zero value of QueueSortKey mean?
And why sometimes in this case LogicalBlockAddress field of CDB
is not the same, but nonzero.
Best regards,
SH.
From: “Peter Wieland”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: SCSI port SRB queuing.
>Date: Fri, 7 Jun 2002 09:54:25 -0700
>
>port passes SRBs to the miniport in an arbitrary order. neither the
>driver above (disk) nor the driver below (your miniport) should make any
>assumptions about what order requests will be dispatched into the
>miniport.
>
>the logic for the queueing has changed in just about every release as we
>try to increase scsiport’s performance. Win2k attempts to use a
>modified Cscan algorithm for sorting the queue based on the QueueSortKey
>field in the SRB but that’s not a guarantee.
>
>if you have an upper level driver which needs to complete requests A, B
>and C in that order then it must wait for A to complete before sending B
>and again before sending C.
>
>-p
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
the DDK is stating an implementation detail of the disk/cdrom/sfloppy
drivers as an absolute fact. For example scsi scanners & printers don’t
have media nor do they have offsets from the beginning of the
nonexistant media so for them queue sort key would contain a different
value [note 1].
the class driver can set queue sort key to whatever value it likes. Our
storage drivers use the LBA for read and write requests. They typically
use 0 for other requests. Neither the port driver nor the miniport care
what this value is derived from, they just use it to sort requests.
as to why the LBA in the CDB could be non-zero while the queue sort key
is zero - there are a number of different paths a read/write request
could get created in. For example, the IOCTL_CDROM_RAW_READ code in
cdrom can create a READ CDB and send it down but I suspect [note 2] that
it doesn’t set the QueueSortKey to the appropriate value. Likewise a
WRITE request could come in though one of the pass-through paths [note
3] and the class driver would never touch the QueueSortKey because it
doesn’t try to interpret CDBs that are sent thorugh these paths [note
4].
so the answer is that the value has no actual meaning other than being a
rough guideline about what order would be best for the port driver to
sort pending requests in. No other information should be derived from
its value whether it’s zero or non-zero.
sorry I can’t give a more satisifying answer.
-p
[note 1] the value would most likely be 0 in this case.
[note 2] I said that I suspect this. I haven’t checked the code to
verify this statement.
[note 3] either IOCTL_SCSI_PASS_THROUGH[_DIRECT] or through something
like ASPI
[note 4] some storage people may notice that this isn’t entirely true as
the class driver has in the past blocked COPY CDBs and a few others
-----Original Message-----
From: Shaggy Head [mailto:xxxxx@hotmail.com]
Sent: Friday, June 14, 2002 5:06 AM
To: NT Developers Interest List
Subject: [ntdev] RE: SCSI port SRB queuing.
As I understand QueueSortKey is a sort key for performance increasing
on initiator side. But DDK says that it “Specifies the offset from the
start of the media or zero, depending on the type of the target device”.
What does zero value of QueueSortKey mean? And why sometimes in this
case LogicalBlockAddress field of CDB is not the same, but nonzero.
Best regards,
SH.
From: “Peter Wieland”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: SCSI port SRB queuing.
>Date: Fri, 7 Jun 2002 09:54:25 -0700
>
>port passes SRBs to the miniport in an arbitrary order. neither the
>driver above (disk) nor the driver below (your miniport) should make
>any assumptions about what order requests will be dispatched into the
>miniport.
>
>the logic for the queueing has changed in just about every release as
>we try to increase scsiport’s performance. Win2k attempts to use a
>modified Cscan algorithm for sorting the queue based on the
>QueueSortKey field in the SRB but that’s not a guarantee.
>
>if you have an upper level driver which needs to complete requests A, B
>and C in that order then it must wait for A to complete before sending
>B and again before sending C.
>
>-p
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
> As I understand QueueSortKey is a sort key for performance
increasing on initiator side. But DDK says that it “Specifies the
offset from the start of the media or zero, depending on the type of
the target device”.
What does zero value of QueueSortKey mean?
Both 
This sorting is elevator seeking - a well-known way of disk
optimization.
Max