Virtual SCSI minports - storage expert input requested

OSR_Community_User · October 6, 2005, 3:02am

Before you give me the standard spiel about virtual miniports are
impossible, let me say that’s my belief too.

AND there may be some information that changes things. Specifically I’m
talking about the function StorPortIssueDpc. I worked on a virtual storage
miniport in the past and the root problem was getting SRB’s to complete
without calling into the miniport from the port wrapper. I used an ugly hack
of issuing the DPC that was stored in the device object (it was Gary’s idea,
with some fine tuning on my own). It worked, except on occasion wrote an
unpleasant message to the event log saying a DPC happened without an
interrupt.

I’ve been looking at how to make a virtual storage port/minport work on some
high speed fabric. The storage function is on a virtual bus for the fabric.

It seems like the storport function StorPortIssueDpc, assuming you can call
it from an arbitrary context, would solve the SRB completion problems. You
just queue the SRB you want completed, issue the DPC, and in the DPC
complete the SRB in a proper miniport context. Has anybody looked at this or
tried this. Are there any other intrinsic problems in making a virtual
miniport work?

Microsoft seems to be saying, use iscsiprt, and it seems like there are a
few issues to that approach, like how do you release a miniport+iscsiprt
install package before Longhorn. Actually finding real includes and libs for
iscsiprt is proving non-trivial (Jeff is helping me on that path)

So what do you storage experts say? Is a high performance virtual minport
still impossible with storport? I’m assuming without StorPortIssueDpc that
storport has the same issue as scsiport, of completed SRB’s not getting
really completed until a return from the miniport to the port wrapper
happens?

Jan

OSR_Community_User · October 6, 2005, 4:32am

Just use SCSIPORT and send SRB to yourself to complete the request (try
searching the archives,
there was a long fight between me an Jamey). Works fine, no ugly messages in
the event log, no
timeout delays. Comparing the performance of monilithic SCSI port and SCSI
miniport there’s something
like 10-20% difference (SCSI port is faster of course) depending of the
lower edge you use (we used both
DISPATCH_LEVEL TDI and reading local disk, not sure what kind of
architecture you’ll have…). I really
suspect to have the same differerence between iscsiprt and monilithic SCSI
port as well.

It would be nice if Jeff or you would find some free minutes to help me with
iscsiprt headers/libraries
I’d love to have experimental port of our iSCSI initiator to MS iscsiprt to
compare the performance. Maybe
there’s no need in monolithic SCSI ports at all… Maybe there’s no need in
walking long road finding iscsiprt
headers/libraries

Regards,
Anton Kolomyeytsev

CEO, Rocket Division Software

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, October 06, 2005 10:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Virtual SCSI minports - storage expert input requested

Before you give me the standard spiel about virtual miniports are
impossible, let me say that’s my belief too.

AND there may be some information that changes things. Specifically I’m
talking about the function StorPortIssueDpc. I worked on a virtual storage
miniport in the past and the root problem was getting SRB’s to complete
without calling into the miniport from the port wrapper. I used an ugly hack
of issuing the DPC that was stored in the device object (it was Gary’s idea,
with some fine tuning on my own). It worked, except on occasion wrote an
unpleasant message to the event log saying a DPC happened without an
interrupt.

I’ve been looking at how to make a virtual storage port/minport work on some
high speed fabric. The storage function is on a virtual bus for the fabric.

It seems like the storport function StorPortIssueDpc, assuming you can call
it from an arbitrary context, would solve the SRB completion problems. You
just queue the SRB you want completed, issue the DPC, and in the DPC
complete the SRB in a proper miniport context. Has anybody looked at this or
tried this. Are there any other intrinsic problems in making a virtual
miniport work?

Microsoft seems to be saying, use iscsiprt, and it seems like there are a
few issues to that approach, like how do you release a miniport+iscsiprt
install package before Longhorn. Actually finding real includes and libs for
iscsiprt is proving non-trivial (Jeff is helping me on that path)

So what do you storage experts say? Is a high performance virtual minport
still impossible with storport? I’m assuming without StorPortIssueDpc that
storport has the same issue as scsiport, of completed SRB’s not getting
really completed until a return from the miniport to the port wrapper
happens?

Jan

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · October 6, 2005, 5:19am

Hi Anton,

What you describe I once tried, and does not always work. Specifically, if
there are any serialized SRB’s, you can’t send new SRB’s until the
serialized one completes. There is a bit in the SRB that controls this, I
believe SRB_FLAGS_DISABLE_DISCONNECT. The storage class drivers like to
serialize SRB’s when they detect SCSI errors. Your systems basically get’s
stuck sometimes if your depending on sending new SRB’s to complete an
existing one.

So far, I don’t have iscsiprt headers, although Jeff is looking into the
proper hoops to jump through to get them.

Jan

Just use SCSIPORT and send SRB to yourself to complete the request (try
searching the archives,

there was a long fight between me an Jamey). Works fine, no ugly messages in
the event log, no

timeout delays. Comparing the performance of monilithic SCSI port and SCSI
miniport there’s something

like 10-20% difference (SCSI port is faster of course) depending of the
lower edge you use (we used both

DISPATCH_LEVEL TDI and reading local disk, not sure what kind of
architecture you’ll have…). I really

suspect to have the same differerence between iscsiprt and monilithic SCSI
port as well.

It would be nice if Jeff or you would find some free minutes to help me with
iscsiprt headers/libraries

I’d love to have experimental port of our iSCSI initiator to MS iscsiprt to
compare the performance. Maybe

there’s no need in monolithic SCSI ports at all… Maybe there’s no need in
walking long road finding iscsiprt

headers/libraries

Regards,

Anton Kolomyeytsev

CEO, Rocket Division Software

OSR_Community_User · October 6, 2005, 6:56am

Jan,

you need to set both flags SRB_FLAGS_BYPASS_FROZEN_QUEUE and
SRB_FLAGS_BYPASS_LOCKED_QUEUE
and described approach works just fine (with some of the tuning). However I
agree it’s a hack and going full blown
SCSI port or iSCSIprt miniport is correct approach (there are some issues
howerver if you want to make your
virtual storage driver bootable - it’s what we’re busy with right now).

If you’d find a way to share headers/libraries it would be just great! I’ll
drop a reminder to Jeff right now

Regards,
Anton Kolomyeytsev

CEO, Rocket Division Software

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, October 06, 2005 12:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Virtual SCSI minports - storage expert input requested

Hi Anton,

What you describe I once tried, and does not always work. Specifically, if
there are any serialized SRB’s, you can’t send new SRB’s until the
serialized one completes. There is a bit in the SRB that controls this, I
believe SRB_FLAGS_DISABLE_DISCONNECT. The storage class drivers like to
serialize SRB’s when they detect SCSI errors. Your systems basically get’s
stuck sometimes if your depending on sending new SRB’s to complete an
existing one.

So far, I don’t have iscsiprt headers, although Jeff is looking into the
proper hoops to jump through to get them.

Jan