All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Volker Lendecke <vl@samba.org>
Subject: Re: Splice on blocking TCP sockets again..
Date: Wed, 30 Sep 2009 08:00:04 +0200	[thread overview]
Message-ID: <4AC2F3E4.5000904@gmail.com> (raw)
In-Reply-To: <4AC2F1D9.1010801@gmail.com>

Eric Dumazet a écrit :
> Jason Gunthorpe a écrit :
>>> One way to handle this is to switch tcp_read() to use the underlying file O_NONBLOCK
>>> flag, as other socket operations do. And let SPLICE_F_NONBLOCK control the pipe output only.
> 
> arg, this was tcp_splice_read() of course
> 
>> Thanks Eric, this seems reasonable from my userspace perspective.
>>
>> I admit I don't understand why SPLICE_F_NONBLOCK exists, it seems very
>> un-unixy to have a syscall completely ignore the NONBLOCK flag of the
>> fd it is called on. Ie setting NONBLOCK on the pipe itself does
>> nothing when using splice..
>>
> 
> Hmm, good question, I dont have the answer but I'll digg one.
> 

commit	29e350944fdc2dfca102500790d8ad6d6ff4f69d
splice: add SPLICE_F_NONBLOCK flag

It doesn't make the splice itself necessarily nonblocking (because the
actual file descriptors that are spliced from/to may block unless they
have the O_NONBLOCK flag set), but it makes the splice pipe operations
nonblocking.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>


See Linus intention was pretty clear : O_NONBLOCK should be taken into account
by 'actual file that are spliced from/to', regardless of SPLICE_F_NONBLOCK flag


  reply	other threads:[~2009-09-30  6:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-30  0:48 Splice on blocking TCP sockets again Jason Gunthorpe
2009-09-30  4:54 ` Eric Dumazet
2009-09-30  5:40   ` Jason Gunthorpe
2009-09-30  5:51     ` Eric Dumazet
2009-09-30  6:00       ` Eric Dumazet [this message]
2009-09-30  6:19         ` Eric Dumazet
2009-10-01 22:17         ` Jason Gunthorpe
2009-09-30  6:37 ` Volker Lendecke
2009-10-02 17:10   ` Jason Gunthorpe
2009-10-02 18:05     ` 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=4AC2F3E4.5000904@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=netdev@vger.kernel.org \
    --cc=vl@samba.org \
    /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.