On Sun, Jan 11, 2009 at 05:00:37PM +0100, Eric Dumazet (dada1@cosmosbay.com) wrote:

quoted text
> >>>> 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 ?

> >

> > Sorry, I meant that we drop lock in skb_splice_bits() to prevent the deadlock,

> > and tcp_splice_read() needs it to process the backlog.

>

> While we drop lock in skb_splice_bits() to prevent the deadlock, we

> also process backlog at this stage. No need to process backlog

> again in the higher level function.

Yes, but having it earlier allows to receive new skb while processing

already received.
> > I think that even with non-blocking splice that release_sock/lock_sock

quoted text
> > is needed, since we are able to do a parallel job: to receive new data

> > (scheduled by early release_sock backlog processing) in bh and to

> > process already received data via splice codepath.

> > Maybe in non-blocking splice mode this is not an issue though, but for

> > the blocking mode this allows to grab more skbs at once in skb_splice_bits.

>

> skb_splice_bits() operates on one skb, you lost me :)

Exactly, and to have it we earlier release a socket so that it could be

acked and while we copy it or doing anything else, the next one would

received.
--

	Evgeniy Polyakov

--

To unsubscribe from this list: send the line "unsubscribe netdev" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html