[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1354117635.21562.63.camel@shinybook.infradead.org>
Date: Wed, 28 Nov 2012 15:47:15 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Vijay Subramanian <subramanian.vijay@...il.com>,
David Miller <davem@...emloft.net>, saku@...i.fi,
rick.jones2@...com, netdev@...r.kernel.org
Subject: Re: TCP and reordering
On Wed, 2012-11-28 at 04:52 -0800, Eric Dumazet wrote:
> BQL is nice for high speed adapters.
For adapters with hugely deep queues, surely? There's a massive
correlation between the two, of course — but PPP over L2TP or PPPoE
ought to be included in the classification, right?
> For slow one, you always can stop the queue for each packet given to
> start_xmit()
>
> And restart the queue at TX completion.
Well yes, but only if we get notified of TX completion.
It's simple enough for the tty-based channels, and we can do it with a
vcc->pop() function for PPPoATM. But for PPPoE and L2TP, how do we do
it? We can install a skb destructor... but then we're stomping on TSQ's
use of the destructor by orphaning it too soon.
I'm pondering something along the lines of
if (skb->destructor) {
newskb = skb_clone(skb, GFP_KERNEL);
if (newskb) {
skb_shinfo(newskb) = skb;
skb = newskb;
}
}
skb_orphan(skb);
skb->destructor = ppp_chan_tx_completed;
... and then ppp_chan_tx_completed can also destroy the original skb
(and hence invoke TSQ's destructor too) when the time comes. And in the
(common?) case where we don't have an existing destructor, we don't
bother with the skb_clone.
But I wish there was a nicer way to chain destructors. And no, I don't
count what GSO does. We can't use the cb here anyway since we're passing
it down the stack.
--
dwmw2
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6171 bytes)
Powered by blists - more mailing lists