Off-loading work from StartIO

Hi All,

We are writing a Virtual Storport Miniport driver for a custom device. There is requirement to off-load the Read/Write SRBs from StartIO onto a driver thread. We are returning SRB_STATUS_PENDING from StartIO and we are completing the SRBs from the driver thread.

We were experimenting the above on a RAM Disk implementation. The observation was that the performance (measured using IOMeter) got halved when we started off-loading the work to a driver thread when compared to completing the requests in StartIO itself. Is this because of the fact that StartIO runs at DISPATCH LEVEL and the driver thread runs at PASSIVE LEVEL and the thread would get very little time to run?

We tried setting the thread’s affinity to specific processor and even then it didn’t help. Is there anything that we are missing?

Regards,
AY

> Hi All,

We are writing a Virtual Storport Miniport driver for a custom device.
There
is requirement to off-load the Read/Write SRBs from StartIO onto a
driver
thread. We are returning SRB_STATUS_PENDING from StartIO and we are
completing
the SRBs from the driver thread.

We were experimenting the above on a RAM Disk implementation. The
observation
was that the performance (measured using IOMeter) got halved when we
started
off-loading the work to a driver thread when compared to completing
the
requests in StartIO itself. Is this because of the fact that StartIO
runs at
DISPATCH LEVEL and the driver thread runs at PASSIVE LEVEL and the
thread
would get very little time to run?

We tried setting the thread’s affinity to specific processor and even
then it
didn’t help. Is there anything that we are missing?

If it truly is a ramdisk with zero latency, why would you expect
anything else? Instead of completing the io operation immediately you
are waiting for your thread to be scheduled which takes huge numbers of
clock cycles compared to simply completing the request right there and
then.

If you are on a single CPU system, read the TSC
(KeQueryPerformanceCounter) at the start of your startio, do your io
work, then read the TSC again at the end before completing and calculate
the difference. Then try again with the driver thread and do the second
read of the TSC when completing there. I think you’ll be surprised at
the time it can take for your thread to be scheduled.

(If you have multiple CPU’s you won’t get useful results as your thread
may be running on a different cpu when you take the second reading.)

James

Hi James,

Thanks for the response. I was using RAM-Disk just to see if there will be any performance loss incurred while off-loading work to the thread. In the final implementation we would need the thread as we have to do some more processing before performing the read/write operation.

–AY

Hi again,

I guess my previous post is a little misleading. I am using RAM-Disk to see what will be the performance loss and whether the miniport will be able to receive another request while the thread is processing the previous one. From the experiments it seems that the overlap is not happening. So I wanted to know if there is a way to achieve this.

Thanks,
AY

If I recall you need to be on StorPort context to complete requests which won’t be the case in a thread. What mechanism is being used to switch back to call StorPortNotification?

From the thread we are sending an IRP back to the miniport with a pointer to the SRB and in the ProcessServiceRequest function we are completing the SRB. The other question is whether completing the SRB within Storport’s context is mandatory. We were able to complete it directly from the thread’s context also.

> If I recall you need to be on StorPort context to complete requests

Virtual miniport has no such requirement.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>StartIO runs at DISPATCH LEVEL and the driver thread runs at PASSIVE LEVEL and the thread

would get very little time to run?

Scheduling delay before the thread is really awaken? try raising its priority.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Did you set command depth/tag queue/multiple request per LU properly?

-----Original Message-----
From: xxxxx@gmail.com [mailto:xxxxx@gmail.com]
Sent: Tuesday, June 01, 2010 6:39 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Off-loading work from StartIO

Hi again,

I guess my previous post is a little misleading. I am using RAM-Disk to see what will be the performance loss and whether the miniport will be able to receive another request while the thread is processing the previous one. From the experiments it seems that the overlap is not happening. So I wanted to know if there is a way to achieve this.

Thanks,
AY


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

On Tue, Jun 1, 2010 at 4:49 AM, wrote:

> We are returning SRB_STATUS_PENDING from StartIO

Really?

BOOLEAN
HwStorStartIo (
IN PVOID DeviceExtensionms-help:
,
IN PSCSI_REQUEST_BLOCK
Srbms-help:

);

Did you mean that you were calling StorPortNotification for the SRB
indicating SRB_STATUS_PENDING? Because that would be wrong too.

You need to indicate an appropriate queue depth and just queue the srbs. The
IRPs are already “STATUS_PENDING”.

Mark Roddy</ms-help:></ms-help:>

@Ajit_Yagaty Same problem when I tried the sample and modify it to schedule SRBs from startio routine to a system thread, the read performance is really slow, are there any workaround or suggestions?

You know you’re responding to a ten year old post, right?

Right.

Peter

Yeah, recently we tried to migrate from virtual scsi miniport(network storage) to storport, is it an wise chosen?

Yea… well, what you’re doing is called “necroposting” and is explicitly disallowed in this forum.

But, you know that, because you read the Read Before Posting link that appears on every page of this forum, right?

People… is it really too much to expect you to read the guidelines before you seek help here? Really?

Thread closed.

Peter