[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090111125759.GB24173@ioremap.net>
Date: Sun, 11 Jan 2009 15:58:00 +0300
From: Evgeniy Polyakov <zbr@...emap.net>
To: Eric Dumazet <dada1@...mosbay.com>
Cc: Willy Tarreau <w@....eu>, David Miller <davem@...emloft.net>,
ben@...s.com, jarkao2@...il.com, mingo@...e.hu,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
jens.axboe@...cle.com
Subject: Re: [PATCH] tcp: splice as many packets as possible at once
Hi Eric.
On Sat, Jan 10, 2009 at 08:40:05AM +0100, Eric Dumazet (dada1@...mosbay.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.
> 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?
--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists