My experience, in the context of my particular driver, the code in the IO
path is less complex using events and shared memory.
KM:
1 set request event
2 wait for complete event
UM:
1 wait for request event
2 process request
3 set complete event
4 goto 1
On Thu, Jan 15, 2015 at 6:09 PM, Marion Bond wrote:
> I don’t know what unit a 'meg’ is, but it sounds like your performance
> improved. I can’t imagine how any coding would be simplified however as
> receiving event signals and then checking memory locations is always going
> to be more complex then having the buffers handed to you; not to mention
> handling the race conditions and other edge cases. Without knowing anything
> at all about your code, I would be surprized if memory mapping was the
> limiting factor in performance, but if it were, then
> SetFileIoOverlappedRange can help. The bigger win usually comes from
> proper threading and or GetQueuedCompletionStatusEx depending on the nature
> of the requests (can they be processed orthogonally, or is there context)
>
> In any case, you know your code better, but my experience suggest that
> correct handling of the state of a shared memory buffer has a comparable
> cost in performance to simply using IOCTLs and is vastly more complex to
> code
>
> Sent from Surface Pro
>
> From: Jamey Kirby
> Sent: Wednesday, January 14, 2015 6:29 PM
> To: Windows System Software Devs Interest List
>
> Using reverse IOCTL I was getting about 3.5 meg throughput. Using shared
> memory I am getting around 14 meg. That is on my test rig; nothing special.
> Performance was improved. The job of the UM coders was made easier too.
>
> With reverse IOCTL, I had to send an IOCTL per request. If I process a
> million of those, there is overhead. With shared memory (section objects),
> the memory is mapped up front and stays mapped until the UM process
> disconnect or exits.
>
>
> On Wed, Jan 14, 2015 at 6:18 PM, Marion Bond
> wrote:
>
>> Did you compare the performance against a simple IOCTL implementation?
>> Chances are that if you have no race conditions or other logic errors, you
>> have rewritten the same thing
>>
>> Sent from Surface Pro
>>
>> From: Jamey Kirby
>> Sent: Wednesday, January 14, 2015 4:49 PM
>> To: Windows System Software Devs Interest List
>>
>> I just finished a driver where I share events and a section object
>> between user-mode and kernel-mode. It works great. Performance is high.
>> IOCTLs are OK for simple things, but reverse-callbacks are a pain in the
>> arse; not to mention that they make me nervous.
>>
>> On Wed, Jan 14, 2015 at 3:07 PM, Doğan Kurt
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I like communicating via communication port in minifilter drivers. But i
>>> don’t want to register a minifilter driver to use this kind of
>>> communication every time.
>>>
>>> Can i use existing kernel objects, like files, pipes, sockets to
>>> communicate with my driver. Which way would you choose if you had to create
>>> a generic protocol between kernel and user, without ioctls or irp major
>>> functions.
>>>
>>> Please forgive my ignorance, if i asked something stupid :).
>>> Thanks in advance.
>>> — NTDEV is sponsored by OSR Visit the list at:
>>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>>> http://www.osr.com/careers 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
>>
>>
>>
>>
>> –
>> Jamey Kirby
>> Disrupting the establishment since 1964
>>
>> This is a personal email account and as such, emails are not subject to
>> archiving. Nothing else really matters.
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers 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
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>>
>
>
>
> –
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to
> archiving. Nothing else really matters.
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
–
Jamey Kirby
Disrupting the establishment since 1964
This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.