Re: TCP and reordering

On Wed, 2012-11-28 at 04:26 -0800, Eric Dumazet wrote:

On Wed, 2012-11-28 at 11:49 +0000, David Woodhouse wrote:

quoted

On Wed, 2012-11-28 at 03:02 -0800, Eric Dumazet wrote:

quoted

quoted

Thanks. For me after a 64MiB download, I have an increase of one FACK,
one SACK and one TS reorder. So my connection probably does even less
reordering than I thought, and thus isn't particularly relevant to this
conversation. I'll shut up now and go back to playing with ATM.

But you are the receiver. A receiver should not increase these counters.

I checked it on the sending side.

If you want to play with reordering effects on your bi-ADSL line,
you could install an "netem delay 3ms" on ingress side of one of the
link.

For now I'm content to observe that I don't really get much reordering
at all, which is fine.

I'll go back to looking at TSQ, and BQL for PPP. If I have to use
skb_orphan() and install a destructor of my own in order to do BQL for
PPP, that'll upset TSQ a little. Is there a way we could *chain* the
destructors... skb_clone() to put the skbs on the PPP channels' queues,
perhaps, then free the original from the PPP destructor? Or is that too
much overhead?

I've killed most of the channel queue for PPPoATM and PPPoE now, but
L2TP still has a whole load of buffering all the way through the stack
again before it really leaves the host.

(And PPPoE will still have the txqueuelen on the Ethernet device too).

-- 
dwmw2