User <-> kernel communication for a mini-filter.

NTFSD
1

Hi,

I’m trying to figure out the right method for the communication.
The choices are the communication port vs. the classic IOCTL-based scheme.
The goal is to implement the fastest data path possible.
I’m a little puzzled about the statement saying “Communication through
a communication port is not buffered, so it is faster and more
efficient.” in the WDK documentation because, as I can see there, both
FtlSendMessage() and FilterGetMessage() require IN buffer pointers, so
there must be some copying going on behind the scenes.

I’ll be glad to hear any suggestions.

Thanks in advance,
Greg.

2

I think the documentation simply means that the IOCTLs used internally are
using METHOD_NEITHER ("Defining I/O Control
Codes"http://msdn.microsoft.com/en-us/library/ff543023(VS.85).aspx). Which i
take it to mean that it goes straight from the sender’s buffer into the
receiver’s buffer, which means there is no intermediate buffering. But there
is indeed a buffer copy involved.

It is pretty fast, but in theory you can always write a faster custom
solution. It is worth pointing out that it already is an IOCTL-based scheme.
I suppose you could implement a faster IOCTL-based mechanism if you were the
producer of data and could write directly into the user’s buffer.

My advice would be to try it out first and see if it isn’t already fast
enough, you might save some time.

Thanks,
Alex.

3

Thanks a lot, Alex.

I suppose you could implement a faster IOCTL-based mechanism if you were the
producer of data and could write directly into the user’s buffer.

That’s exactly the thing I was thinking about.
If I have queued IRPs having the buffer locked, I can avoid that
unnecessary copy.
I was just wondering how the port is implemented internally.

Greg.

On Thu, Oct 7, 2010 at 5:47 PM, Alex Carp wrote:
> I think the documentation simply means that the IOCTLs used internally are
> using METHOD_NEITHER ("Defining I/O Control
> Codes"http://msdn.microsoft.com/en-us/library/ff543023(VS.85).aspx). Which i
> take it to mean that it goes straight from the sender’s buffer into the
> receiver’s buffer, which means there is no intermediate buffering. But there
> is indeed a buffer copy involved.
>
> It is pretty fast, but in theory you can always write a faster custom
> solution. It is worth pointing out that it already is an IOCTL-based scheme.
> I suppose you could implement a faster IOCTL-based mechanism if you were the
> producer of data and could write directly into the user’s buffer.
>
> My advice would be to try it out first and see if it isn’t already fast
> enough, you might save some time.
>
> Thanks,
> Alex.
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>

4

Internally it’s just using some METHOD_NEITHER IOCTLs. FltSendMessage for
example will lock the user’s buffer and then memcpy the data from the buffer
in FltSendMessage into the user’s buffer. It would be nice if it were to
provide a method like “FltGetUserBufferMDL” which would get you a MDL for
the user’s buffer…

Thanks,
Alex.