From: Evgeniy Polyakov

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

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

> > > 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.

I think the socket release in skb_splice_bits() (although necessary)

just muddies the waters, and whether the extra one done in

tcp_splice_read() helps at all is open to debate.
That skb_clone() done by skb_splice_bits() pisses me off too,

we really ought to fix that.  And we also have that data corruption

bug to cure too.

--

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