Messages in this thread | | | Date | Sun, 11 Jan 2009 14:14:57 +0100 | From | Eric Dumazet <> | Subject | Re: [PATCH] tcp: splice as many packets as possible at once |
| |
Evgeniy Polyakov a écrit : > Hi Eric. > > On Sat, Jan 10, 2009 at 08:40:05AM +0100, Eric Dumazet (dada1@cosmosbay.com) wrote: >>> Not to interrupt the discussion, but for the clarification, that >>> release_sock/lock_sock is used to process the backlog accumulated while >>> socket was locked. And while dropping additional pair before the final >>> release is ok, but moving this itself should be thought of twice. >>> >> Hum... I just caught the release_sock(sk)/lock_sock(sk) done in skb_splice_bits() >> >> So : >> >> 1) the release_sock/lock_sock done in tcp_splice_read() is not necessary >> to process backlog. Its already done in skb_splice_bits() > > Yes, in the tcp_splice_read() they are added to remove a deadlock.
Could you elaborate ? A deadlock only if !SPLICE_F_NONBLOCK ?
> >> 2) If we loop in tcp_read_sock() calling skb_splice_bits() several times >> then we should perform the following tests inside this loop ? >> >> if (sk->sk_err || sk->sk_state == TCP_CLOSE || (sk->sk_shutdown & RCV_SHUTDOWN) || >> signal_pending(current)) break; >> >> And removie them from tcp_splice_read() ? > > It could be done, but for what reason? To detect disconnected socket early? > Does it worth the changes? >
I was thinking about the case your thread is doing a splice() from tcp socket to a pipe, while another thread is doing the splice from this pipe to something else.
Once patched, tcp_read_sock() could loop a long time...
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |