On Mon, Feb 25, 2013 at 2:22 PM, Eric Dumazet <[email protected]> wrote:
> I don't understand the issue.
>
> sendfile() returns -EAGAIN only if no bytes were copied to the socket.
There is something wrong/unexpected/...
I have a program which can use either sendfile or send. When using
sendfile to transmit a large block (I've seen it with 900k) the
sendfile call does not transmit everything. There receiver gets only
about 600k. This is the situation when I think I've seen EAGAIN
errors from sendmail but I cannot just now reproduce it. This is with
sockets of AF_UNIX type.
Are there any limits to take into account?
On Sat, 2013-03-02 at 20:41 -0500, Ulrich Drepper wrote:
> On Mon, Feb 25, 2013 at 2:22 PM, Eric Dumazet <[email protected]> wrote:
> > I don't understand the issue.
> >
> > sendfile() returns -EAGAIN only if no bytes were copied to the socket.
>
> There is something wrong/unexpected/...
>
> I have a program which can use either sendfile or send. When using
> sendfile to transmit a large block (I've seen it with 900k) the
> sendfile call does not transmit everything. There receiver gets only
> about 600k. This is the situation when I think I've seen EAGAIN
> errors from sendmail but I cannot just now reproduce it. This is with
> sockets of AF_UNIX type.
There is no real sendfile() support for AF_UNIX.
It does a copy.
( sock_no_sendpage() fallback )
>
> Are there any limits to take into account?
This is totally expected that sendfile() doesn't queue the whole file,
if the transport is slower than the producer.
You cant ask for non blocking operation and expect sendfile() storing
Gigabytes of data in the kernel, even if its only meta data.
Using non blocking IO means the sender (and the receiver) must be able
to perform several operations, as long as the whole transfert is not
finished.
On Sat, Mar 2, 2013 at 10:09 PM, Eric Dumazet <[email protected]> wrote:
>
> Using non blocking IO means the sender (and the receiver) must be able
> to perform several operations, as long as the whole transfert is not
> finished.
Certainly, and this is implemented. But the receiver never gets the
rest of the data while the sender (most of the time) gets notified
that everything is sent.
I don't have a reduced test case yet. Hopefully I'll get to it
sometime soon. For now I worked around it by not using sendfile.
Ulrich Drepper <[email protected]> wrote:
> On Mon, Feb 25, 2013 at 2:22 PM, Eric Dumazet <[email protected]> wrote:
> > I don't understand the issue.
> >
> > sendfile() returns -EAGAIN only if no bytes were copied to the socket.
>
> There is something wrong/unexpected/...
>
> I have a program which can use either sendfile or send. When using
> sendfile to transmit a large block (I've seen it with 900k) the
> sendfile call does not transmit everything. There receiver gets only
> about 600k. This is the situation when I think I've seen EAGAIN
> errors from sendmail but I cannot just now reproduce it. This is with
> sockets of AF_UNIX type.
If you manage to reproduce it, can you pass an offset to sendfile() and
see if the offset changed when you get EAGAIN?
Also, which kernel version are you using? Perhaps it's triggered
by memory pressure.
On Mon, Mar 4, 2013 at 5:28 AM, Eric Wong <[email protected]> wrote:
> If you manage to reproduce it, can you pass an offset to sendfile() and
> see if the offset changed when you get EAGAIN?
I did that and didn't see the offset to change.
> Also, which kernel version are you using? Perhaps it's triggered
> by memory pressure.
That was with the RHEL6.2 kernel. I don't have the details as to what
patches are included on top of 2.6.32...