Yes, the IOCTL approach is what should be used, and is basically the
inverted call if you use multiple IOCTL and STATUS_PENDING.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthieu Collette
Sent: Tuesday, August 30, 2016 11:20 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IOCTL as an alternative to WINSOCK for the most direct
data path to user space ?
On 2016-08-30 15:12:55 +0000, Don Burn said:
> Premature optimization, such as the circular buffer suggested below, is
the
> biggest cause of unreliable drivers. Start with the IOCTL approach, and
> only after you have measured performance and if it is unacceptable
> profiled the driver to determine that the IOCTL mechanism is the
> problem should you consider other mechanisms.
>
>
> Don Burn
> Windows Driver Consulting
> Website: http://www.windrvr.com
Hi !
By IOCTL approach you refer to the two first solutions suggested by slavaim
?
I have not yet read the article about the Inverted Call Model, what’s your
opinion about that ?
Thanks for you help !
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@hotmail.com
> Sent: Tuesday, August 30, 2016 10:59 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] IOCTL as an alternative to WINSOCK for the most
> direct data path to user space ?
>
> If you want to continue with IOCTLs then a simplest solution is to
> issue an IOCTL from a user application and either block IRP in the
> driver or return STATUS_PENDING(do not forget IoMarkIrpPending ). In
> DPC you fill the IRP’s buffer and call IoCompleteRequest for the
pending/blocked IRP.
>
> An evolution of this approach to reduce the latency and increase
> throughput is issuing multiple asynchronous IOCTLS and waiting for
> their completion ( overlapped IO ). The driver puts IRPs in a list and
returns STATUS_PENDING.
> DPC removes an IRP from the list, fills data and completes the IRP.
>
> There is another solution which probably has the lowest latency and
> highest throughput - circular buffer. A user application allocates a
> buffer and an event. Sends them to a driver via IOCTL. The driver
> locks the
> buffer(MmProbeAndLockPages) so it can be used in DPC and gets a
> pointer to an event object ( ObReferenceObjectByHandle ). Both the
> driver and the user application implement a circular buffer. The
> driver writes in it and the application reads from the buffer. A
> single reader/single write circular buffer can be implemented w/o any
> lock as long as the pointer arithmetic is atomic, which is a case on
> IA-32 and AMD-64 architectures for aligned pointers, i.e. when
> (address mod sizeof(void*)) == 0 or
> address%sizeof(void*) == 0 . The DPC routine writes into the circular
> buffer and sets the event in a signal state. The user application
> waits on the event. When WaitForSingleObject returns it reads data
> from the buffer until it becomes empty and returns to waiting on the
event.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at:
> http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:
—
NTDEV is sponsored by OSR
Visit the list online at:
http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:></http:></http:></http:>