On NT you can set the kernel buffer size on the socket to 0 ( with
setockopt() or ioctlsocket()? ), and the NIC can DMA directly from the
user buffers to send rather than copy to kernel space. This of course,
requires that you keep more than one pending async operation so the nic
allways has a buffer availible so it can keep the line saturated. If
you memory map the source file from the disk, then zero copy IO can be
done entirely from user space. Is this optimization not availible on
linux or freebsd?
As an alternative, you can bypass the cache and do direct async IO to
the disk with zero copies. IIRC, this is supported on linux with the
O_DIRECT flag. Doing this though, means that you will need to handle
caching yourself, which might not be such a good idea. Does Linux not
support O_DIRECT on sockets?
By using this technique I have been able to achieve TransmitFile()
performance levels entirely from user space, without any of the
drawbacks of TransmitFile(). Specifically virtually zero cpu time is
needed to saturate multiple 100 MBps links, pushing 11,820 KB/s,
progress is known the entire time and can be canceled at any time, and a
small handfull of threads can service thousonds of clients.
Paul Querna wrote:
Phillip Susi wrote:
On what OS? Linux? NT supports async IO on sockets rather nicely, as
does FreeBSD iirc.
The event MPM doesn't run on NT at all, only Unixes.
Yes, FreeBSD (and linux) support async_write().. But this requires that
you read the file off of disk, and into a buffer, and then copy it back
into the kernel. With a non-blocking sendfile, we can avoid all the
data copying (aka 'zero copy'), and let the kernel do everything itself.
There is currently no such thing as 'async sendfile', which would be the
perfect solution for this use case. There have been various people
mentioning it as an idea, but no one has gone out and done it.
-Paul
