From: Eric Dumazet <dada1@cosmosbay.com>
To: Volker.Lendecke@SerNet.DE
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Steven French <sfrench@us.ibm.com>,
Jens Axboe <jens.axboe@oracle.com>,
netdev@vger.kernel.org
Subject: Re: maximum buffer size for splice(2) tcp->pipe?
Date: Wed, 14 Jan 2009 10:13:34 +0100 [thread overview]
Message-ID: <496DACBE.3030701@cosmosbay.com> (raw)
In-Reply-To: <E1LN0MC-00DaJs-M2@intern.SerNet.DE>
Volker Lendecke a écrit :
> On Wed, Jan 14, 2009 at 12:15:04AM +0100, Eric Dumazet wrote:
>> Volker, your splice() is a blocking one, from tcp socket to a pipe ?
>
> Yes, it is.
>
>> If no other thread is reading the pipe, then you might block forever
>> in splice_to_pipe() as soon pipe is full (16 pages).
>
> Why does it block when the pipe is full? Why doesn't it
> return a short read, just like the read(2) call does? We
> need to cope with that behaviour anyway.
Well, check code in fs/splice.c, function splice_to_pipe().
If SPLICE_F_NONBLOCK is not set, it is *expected* to block on pipe.
In this mode, only another thread is able to drain the pipe and wakeup the blocked thread.
Code review :
When all pages are used "if (pipe->nrbufs == PIPE_BUFFERS)"
if (spd->flags & SPLICE_F_NONBLOCK) {
if (!ret)
ret = -EAGAIN;
break;
}
if (signal_pending(current)) {
if (!ret)
ret = -ERESTARTSYS;
break;
}
if (do_wakeup) {
smp_mb();
if (waitqueue_active(&pipe->wait))
wake_up_interruptible_sync(&pipe->wait);
kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
do_wakeup = 0;
}
pipe->waiting_writers++;
HERE >> pipe_wait(pipe);
pipe->waiting_writers--;
>
>> As pages are not necessarly full (each skb will use at least one page, even if
>> its length is small), it is not really possible to use splice() like this.
>>
>> In your case, only safe way with current kernel would be to call splice()
>> asking for no more than 16 bytes, that would be really insane for your needs.
>>
>> You may prefer a non blocking mode, at least when calling splice_to_pipe()
>
> Which fd do I have to set the nonblocking flag on? The TCP
> socket I read from, or the pipe I write to?
I would say, use the SPLICE_F_NONBLOCK flag on splice() system call,
but let tcp socket in blocking mode... But with current kernel it
wont work. In order to avoid busy looping, you might add a poll()/select()
to call splice(SPLICE_F_NONBLOCK) only when socket has data
in its receive queue.
for (;;) {
struct pollfd pfd;
pfd.fd = socket;
pfd.events = POLLIN;
if (poll(&pfd, 1, -1) != 1)
continue;
res = splice(socket, NULL, pipefds[1], NULL, 65536, SPLICE_F_MOVE|SPLICE_F_NONBLOCK);
if (res > 0)
nwritten = splice(pipefds[0], NULL, file_fd, NULL, res, SPLICE_F_MOVE|SPLICE_F_MORE);
}
splice() from tcp socket to pipe is not working as is unfortunatly if !SPLICE_F_NONBLOCK)
and if using the same thread to write and read the pipe. Or risk deadlock.
next prev parent reply other threads:[~2009-01-14 9:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-08 10:13 maximum buffer size for splice(2) tcp->pipe? Volker Lendecke
2009-01-13 20:37 ` Andrew Morton
2009-01-13 23:15 ` Eric Dumazet
2009-01-13 23:38 ` Eric Dumazet
2009-01-15 4:58 ` David Miller
2009-01-15 11:47 ` Eric Dumazet
2009-01-14 7:40 ` Volker Lendecke
2009-01-14 9:13 ` Eric Dumazet [this message]
2009-01-14 10:03 ` Volker Lendecke
2009-01-14 10:17 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=496DACBE.3030701@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=Volker.Lendecke@SerNet.DE \
--cc=akpm@linux-foundation.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sfrench@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.