Fast I/O

NTDEV
1

Hi all,

I read about the Fast I/O entry points for DeviceIoControl calls.
I am wondering if it is supported in WDM drivers (the structure is available
in wdm.h) because it is not in the DDK docs.
Has anyone used it?
Does it give measurable performance increase?

Thanks,

Martin Gossner

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

They are usually only for filesystems which use Cache Manager.

----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Friday, September 07, 2001 12:54 PM
Subject: [ntdev] Fast I/O

> Hi all,
>
> I read about the Fast I/O entry points for DeviceIoControl calls.
> I am wondering if it is supported in WDM drivers (the structure is
available
> in wdm.h) because it is not in the DDK docs.
> Has anyone used it?
> Does it give measurable performance increase?
>
> Thanks,
>
> Martin Gossner
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

wrote in message news:xxxxx@ntdev…
> I read about the Fast I/O entry points for DeviceIoControl calls.
> I am wondering if it is supported in WDM drivers (the structure is
available
> in wdm.h) because it is not in the DDK docs.
> Has anyone used it?
> Does it give measurable performance increase?
>

Well…

It’s not really documented for use in device drivers… As Max said, it’s
really designed for use by File Systems. But fast I/O for Device I/O
Control does work in WDM drivers. Note that Fast I/O Read and Write do
NOT – They ONLY work for file systems.

There are lots of conditions and requirements for using Fast I/O, and a few
gottcha’s as well. The best way to think of Fast I/O is as a special case of
Type 3 or “Neither I/O”. That is, when the users data buffer is described
by “Neither” Buffered I/O nor Direct I/O. All the special conditions for
Neither I/O pertain: You must be at the top of the device stack, you are
responsible for validating the pointers passed to you, etc. If your driver
is not the first entered from the I/O Manager as a result of a call to
NtDeviceIoControlFile (or the Win32 equivalent) your Fast I/O entry point
will not be called. For example, if you are in a stack with other drivers,
and the driver above you sends you an IRP via IoCallDriver, your driver’s
fast I/O entry point will not be called.

As to the performance gain, it depends. First of all, if your driver meets
the requirements, try using Neither I/O. My experience is that the gain for
most drivers between using an IOCTL with METHOD_NEITHER and Fast I/O for
Device I/O Control is marginal. If you’re writing a very special driver
that’s going to work in a closed, pre-defined, environment, you CAN squeeze
out extra performance by using Fast I/O. But, the drivers I’ve seen (or, I
admit it, have written) that obtain ultimate performance in this way often
do it by sacrificing things like proper parameter validation – Which is
not, I repeat NOT appropriate for general distribution drivers. But, I
digress…

Finally, as Hector noted in his memo on the OSR web site recently, when
running your WDM driver under Driver Verifier your Fast I/O entry point will
NOT be called. So, you’ll need to create a standard dispatch entry point
for Device I/O Control (using METHOD_NEITHER probably) in any case.

HTH,

Peter
OSR

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com