Using sendfile for reducing CPU utilization

[Ephi Dror]

>> (And is there a recvfile?? Never heard of that. Maybe BSD only?)
 
>FreeBSD only implements the send from file to socket in sendfile, but
adds 
>the header. So, I have to add recvfile to do the other direction.
>
>Regards
>-----
>Richard Sharpe, rsharpe at ns.aus.com, rsharpe at samba.org, 
>sharpe at ethereal.com
 
 
Hi all,
 
Isn't special hardware needed to implement recvfile which will zerocopy
data from a socket (incoming data) to a file descriptor (File system
buffer cache)?
 
Just for education, the way zerocopy is done for sendfile is that fs
buffers that hold part of your file are linked as what it called
external mbufs and are given to the stack for sending. If you reuse
those buffers before tcp engine was successfully done sending them and
callback to sf_buf_free and tell you that the mbuff can be freed, you
screwed. 
 
The receive side however is more tricky to implement in the kernel and
requires file system and stack modifications and of course special
hardware to enable this great idea in the first place.
 
Am I missing big time here?
 
If there is a public domain generic implementation of recvfile, I would
love to see it.
 
One more point, in freebsd, sendfile's args are fd and s, in LINUX
however, the args are out_fd and in_fd and they just telling you that
for now, the in_fd must be an open file and the out_fd must be a socket.
This means that in the future if LINUX supports the other way around,
they can stay with the same system call which will allow each fd to be
either an fd or a socket.
 
In regards to adding sendfile support to SAMBA, I think it is pretty
safe and can be easily done. The only issue to take care is the
differences between the OSs in regards to sending the SMB header.
 
Thanks,
Ephi
 
 
 
 
 
 
-------------- next part --------------
HTML attachment scrubbed and removed