CreateNamedPipe function for kernel-mode?

Is there a helper function or otherwise that would allow me to create
a named pipe in a kernel-mode device driver? I have a named-pipe
server that currently runs as a user-mode service and needs to accept
connections from other workstations. I'd like to move it to kernel-
mode. It doesn't do much, mostly just CreateNamedPipe and ReadFileEx
and WriteFileEx on the pipe.

Don
Fri Feb 08 17:15:22 CST 2008

What do you think you would accomplish by moving it to the kernel? None of
the named pipe functions are documented for the kernel (and the internet
doc's of the undocumented calls have some big holes). Not only that but
network support can be a pain in the kernel so you are making things
imensely harder, and I can't see a reason behind this.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply



"eric" <eselk@surfbest.net> wrote in message
news:672a3e46-ac2d-480f-83e2-415bf5a07b04@n20g2000hsh.googlegroups.com...
> Is there a helper function or otherwise that would allow me to create
> a named pipe in a kernel-mode device driver? I have a named-pipe
> server that currently runs as a user-mode service and needs to accept
> connections from other workstations. I'd like to move it to kernel-
> mode. It doesn't do much, mostly just CreateNamedPipe and ReadFileEx
> and WriteFileEx on the pipe.

Maxim
Sat Feb 09 09:40:23 CST 2008

Named pipes are pain containing bugs - like the glorious bug of GetFileType
hanging on a pipe waiting for the pending read to complete, the bug which was
worked around by the C runtime startup code for years (see the source from the
Visual Studio).

So, I would suggest to use inverted calls instead.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"eric" <eselk@surfbest.net> wrote in message
news:672a3e46-ac2d-480f-83e2-415bf5a07b04@n20g2000hsh.googlegroups.com...
> Is there a helper function or otherwise that would allow me to create
> a named pipe in a kernel-mode device driver? I have a named-pipe
> server that currently runs as a user-mode service and needs to accept
> connections from other workstations. I'd like to move it to kernel-
> mode. It doesn't do much, mostly just CreateNamedPipe and ReadFileEx
> and WriteFileEx on the pipe.

eric
Mon Feb 11 13:24:27 CST 2008

On Feb 8, 4:15=A0pm, "Don Burn" <b...@stopspam.windrvr.com> wrote:
> What do you think you would accomplish by moving it to the kernel? =A0None=
of
> the named pipe functions are documented for the kernel (and the internet
> doc's of the undocumented calls have some big holes). =A0Not only that but=

> network support can be a pain in the kernel so you are making things
> imensely harder, and I can't see a reason behind this.
>
> --
> Don Burn (MVP, Windows DDK)

I'm hoping my code will run faster without the transitions from user
to kernel mode. I currently have a user mode process that pretty much
memics the network redirector (the device driver that handles file
sharing). Being at such a low level, it needs to process 1000s of
requests per second (like 1000 ReadFile requests). I know the
transition between the modes should be very minimal, but I've
profilied my current code and cannot see any other way to improve it.
I'm using I/O Completetion Routines at the server, I'm using
TransactNamedPipe on the client, and I've pretty much eliminated all
overhead in my code, to the point that both sides spend 99% of their
time waiting on pipe i/o... and using netmon I can tell that my
packets are the exact same size and number as going through the
network redirector. I've got my test code setup to easily switch the
client between using my server and direct file i/o to the shared
drive, and the direct i/o always wins (10% faster in most cases, but
on slower CPUs or when they are busy doing other things, then up to
400% faster). So all I can figure is the transition is slower *OR*
the "system" process (that the network redirector runs under) has a
higher priority than all others -- either way, I'd need my code to run
in that process to make it faster.

Don
Mon Feb 11 13:33:54 CST 2008

Up the priority and make it a real time process? Seriously, you are looking
at a huge amount of work to move this to the kernel, let alone make it fast.
And that does not count having a huge support problem with the undocumented
calls, or else rewriting your client to use something other than named
pipes.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


"eric" <eselk@surfbest.net> wrote in message
news:cbd15df5-782e-4ecf-a974-80365e673150@h11g2000prf.googlegroups.com...
On Feb 8, 4:15 pm, "Don Burn" <b...@stopspam.windrvr.com> wrote:
> What do you think you would accomplish by moving it to the kernel? None of
> the named pipe functions are documented for the kernel (and the internet
> doc's of the undocumented calls have some big holes). Not only that but
> network support can be a pain in the kernel so you are making things
> imensely harder, and I can't see a reason behind this.
>
> --
> Don Burn (MVP, Windows DDK)

I'm hoping my code will run faster without the transitions from user
to kernel mode. I currently have a user mode process that pretty much
memics the network redirector (the device driver that handles file
sharing). Being at such a low level, it needs to process 1000s of
requests per second (like 1000 ReadFile requests). I know the
transition between the modes should be very minimal, but I've
profilied my current code and cannot see any other way to improve it.
I'm using I/O Completetion Routines at the server, I'm using
TransactNamedPipe on the client, and I've pretty much eliminated all
overhead in my code, to the point that both sides spend 99% of their
time waiting on pipe i/o... and using netmon I can tell that my
packets are the exact same size and number as going through the
network redirector. I've got my test code setup to easily switch the
client between using my server and direct file i/o to the shared
drive, and the direct i/o always wins (10% faster in most cases, but
on slower CPUs or when they are busy doing other things, then up to
400% faster). So all I can figure is the transition is slower *OR*
the "system" process (that the network redirector runs under) has a
higher priority than all others -- either way, I'd need my code to run
in that process to make it faster.

Maxim
Mon Feb 11 16:13:00 CST 2008

>TransactNamedPipe on the client, and I've pretty much eliminated all
>overhead in my code, to the point that both sides spend 99% of their
>time waiting on pipe i/o...

Pipe I/O will give the same overhead as inverted calls.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

eric
Tue Feb 12 12:02:12 CST 2008

On Feb 11, 12:33=A0pm, "Don Burn" <b...@stopspam.windrvr.com> wrote:
> Up the priority and make it a real time process? =A0Seriously, you are loo=
king
> at a huge amount of work to move this to the kernel, let alone make it fas=
t.
> And that does not count having a huge support problem with the undocumente=
d
> calls, or else rewriting your client to use something other than named
> pipes.
>
> --
> Don Burn (MVP, Windows DDK)

Thanks for reminding me that I still hadn't tried changing the
priority. I tried doing it the manual way, from task manager, but I
got an "access denied" message, even though the user is a local
admin. After that I forgot to try again, I'll have to do that. Of
course, someone may argue that doing that will slow down everything
else on the system, but if moving it to kernel mode would also give it
a higher priority (so to speek), then I guess it is somewhat the same
thing.

If someone does mention that, is there something I can show them that
states that the "system" process also runs at a higher priority? Or
maybe the kernel itself, it has a higher priority (so to speek),
right? Just by the nature of it being in ring 0, and basicaly driving
everything else.

Peter
Tue Feb 12 18:27:12 CST 2008

If you are going to go down this route (and as Don mentioned in the other
thread it's a big porting cost with lots of new risk kernel code) you should
do a quick performance prototype and see if moving to kernel is even going
to make a difference.

Even without ring transitions you may still get slowed down by the named
pipe code, which introduces overhead just like any other component would.
I'd hate to do a bunch of work to move my component into the kernel only to
discover that that still wasn't the bottleneck.

-p

--
This posting is provided "AS IS" with no warranties, and confers no rights.


"eric" <eselk@surfbest.net> wrote in message
news:cbd15df5-782e-4ecf-a974-80365e673150@h11g2000prf.googlegroups.com...
> On Feb 8, 4:15 pm, "Don Burn" <b...@stopspam.windrvr.com> wrote:
>> What do you think you would accomplish by moving it to the kernel? None
>> of
>> the named pipe functions are documented for the kernel (and the internet
>> doc's of the undocumented calls have some big holes). Not only that but
>> network support can be a pain in the kernel so you are making things
>> imensely harder, and I can't see a reason behind this.
>>
>> --
>> Don Burn (MVP, Windows DDK)
>
> I'm hoping my code will run faster without the transitions from user
> to kernel mode. I currently have a user mode process that pretty much
> memics the network redirector (the device driver that handles file
> sharing). Being at such a low level, it needs to process 1000s of
> requests per second (like 1000 ReadFile requests). I know the
> transition between the modes should be very minimal, but I've
> profilied my current code and cannot see any other way to improve it.
> I'm using I/O Completetion Routines at the server, I'm using
> TransactNamedPipe on the client, and I've pretty much eliminated all
> overhead in my code, to the point that both sides spend 99% of their
> time waiting on pipe i/o... and using netmon I can tell that my
> packets are the exact same size and number as going through the
> network redirector. I've got my test code setup to easily switch the
> client between using my server and direct file i/o to the shared
> drive, and the direct i/o always wins (10% faster in most cases, but
> on slower CPUs or when they are busy doing other things, then up to
> 400% faster). So all I can figure is the transition is slower *OR*
> the "system" process (that the network redirector runs under) has a
> higher priority than all others -- either way, I'd need my code to run
> in that process to make it faster.

eric
Wed Feb 13 08:26:04 CST 2008

On Feb 12, 11:02=A0am, eric <es...@surfbest.net> wrote:
> On Feb 11, 12:33=A0pm, "Don Burn" <b...@stopspam.windrvr.com> wrote:
>
> > Up the priority and make it a real time process? =A0Seriously, you are l=
ooking
> > at a huge amount of work to move this to the kernel, let alone make it f=
ast.
> > And that does not count having a huge support problem with the undocumen=
ted
> > calls, or else rewriting your client to use something other than named
> > pipes.
>
> > --
> > Don Burn (MVP, Windows DDK)
>
> Thanks for reminding me that I still hadn't tried changing the
> priority.

Uping the priority to high or real-time both had the same results.
The fastest times I was getting before (at normal priority) are still
the same, didn't get any faster, but now I'm getting the faster times
almost all of the time, instead of getting slower times most of the
time. Now I'm within 10% of the network redirector speed, even on a
server that has a slow CPU and lots of other tasks going on. I think
I'm happy with that, and down the road I can see if other things can
improve those speeds (like compression, which the network redirector
doesn't do).

Don
Wed Feb 13 08:32:48 CST 2008


"eric" <eselk@surfbest.net> wrote in message:

>> I think I'm happy with that, and down the road I can see if other things
>> can
>> improve those speeds (like compression, which the network redirector
>> doesn't do).

While SMB does not do compression it is smart enough to read a compressed
file as compressed then transfer it across the wire before uncompressing it
on the client.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply