Hi,
I am trying to beat the I/O bottleneck so as to speed up bulk data transfers
in high speed network. It seems that the system call sendfile() can help to
reduce CPU utilization and speedup data transfers. But I have one question
about the system call,
First, Linux sendfile requires that the input file descriptor cannot be a
network socket. What are the reasons for such a restriction? Sending a
socket to a file via zero copy is definitely useful. Actually this is one
approach I am trying to do to improve performance. Some discussions on
Linux zero copy said this is because it is harder. Sending a socket to a
file via zero copy needs the support of NICs. I cannot understand this
explanation. It seems that FreeBSD has implemented bidirectional zero
copy(http://people.freebsd.org/~ken/zero_copy/#Download). So why Linux does
not support it? What shall I do to release the restriction that Linux
enforces on sendfile?
Any hints will be highly appreciated. Thanks.
Xiuduan Fang
On Mon, 2005-02-07 at 22:26 -0500, Xiuduan Fang wrote:
> Hi,
>
> I am trying to beat the I/O bottleneck so as to speed up bulk data transfers
> in high speed network. It seems that the system call sendfile() can help to
> reduce CPU utilization and speedup data transfers. But I have one question
> about the system call,
>
> First, Linux sendfile requires that the input file descriptor cannot be a
> network socket. What are the reasons for such a restriction? Sending a
> socket to a file via zero copy is definitely useful. Actually this is one
> approach I am trying to do to improve performance. Some discussions on
> Linux zero copy said this is because it is harder. Sending a socket to a
> file via zero copy needs the support of NICs. I cannot understand this
> explanation. It seems that FreeBSD has implemented bidirectional zero
> copy(http://people.freebsd.org/~ken/zero_copy/#Download). So why Linux does
> not support it? What shall I do to release the restriction that Linux
> enforces on sendfile?
>From the URL you posted:
"[zero-copy receive] generally requires some sort of intelligence on the
NIC to make sure that the payload starts in its own buffer. This is
called "header splitting". Currently the only NICs with support for
header splitting are Alteon Tigon 2 based boards running slightly
modified firmware."
Perhaps that explains it.
Not to mention the other complications that are involved if you scroll
down the page and read the FAQ.
Have you done any profiling work to see where your CPU cycles are being
spent?
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source http://www.scaramanga.co.uk/scaramanga.asc | gpg --import