Netdev List
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Vijay Subramanian <subramanian.vijay@gmail.com>,
	David Miller <davem@davemloft.net>,
	saku@ytti.fi, rick.jones2@hp.com, netdev@vger.kernel.org
Subject: Re: TCP and reordering
Date: Wed, 28 Nov 2012 08:09:42 -0800	[thread overview]
Message-ID: <1354118982.14302.356.camel@edumazet-glaptop> (raw)
In-Reply-To: <1354117635.21562.63.camel@shinybook.infradead.org>

On Wed, 2012-11-28 at 15:47 +0000, David Woodhouse wrote:
> 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.
> 

My point was that if you limit number of in flight packet to 1,
its relatively easy to add glue in the priv dev data, so that you chain
the destructor without adding yet another fields in all skbs.

At start_xmit() do the following instead of skb_orphan(skb)

if (skb->destructor) {
     BUG_ON(priv->save_destructor);
     priv->save_destructor = skb->destructor;
     priv->save_sk = skb->sk;
     skb->sk = &priv->fake_sk;
}

skb->destructor = my_destructor;
/* stop the queue */
...
}


void my_destructor(struct sk_buff *skb)
{
    struct .... *priv = container_of(skb, struct ..., priv.fake_sk);

    skb->sk = skb->save_sk;
    priv->save_destructor(skb);
    priv->save_destructor = NULL;
    /* restart the queue */
    ...
}

Something like that.

  reply	other threads:[~2012-11-28 16:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27  9:32 TCP and reordering Saku Ytti
2012-11-27 17:05 ` Rick Jones
2012-11-27 17:15   ` Saku Ytti
2012-11-27 18:00     ` Rick Jones
2012-11-28  2:06     ` David Miller
2012-11-28  7:26       ` Saku Ytti
2012-11-28  8:35         ` Vijay Subramanian
2012-11-28  8:54           ` Saku Ytti
2012-11-28 18:24             ` Rick Jones
2012-11-28 18:33               ` Eric Dumazet
2012-11-28 18:52                 ` Vijay Subramanian
2012-11-28 18:44               ` Saku Ytti
2012-11-28  7:59       ` David Woodhouse
2012-11-28  8:21         ` Christoph Paasch
2012-11-28  8:22         ` Vijay Subramanian
2012-11-28  9:08           ` David Woodhouse
2012-11-28 11:02             ` Eric Dumazet
2012-11-28 11:49               ` David Woodhouse
2012-11-28 12:26                 ` Eric Dumazet
2012-11-28 12:39                   ` David Woodhouse
2012-11-28 12:52                     ` Eric Dumazet
2012-11-28 15:47                       ` David Woodhouse
2012-11-28 16:09                         ` Eric Dumazet [this message]
2012-11-28 16:21                           ` David Woodhouse
2012-11-28 16:19                         ` Benjamin LaHaise
2012-11-28 16:41                           ` David Woodhouse
2012-11-28 17:08                             ` Benjamin LaHaise
2012-11-28 17:16                             ` Eric Dumazet
2012-11-28 18:01                               ` David Woodhouse
2012-11-29 15:10                                 ` Noel Grandin
2012-12-02  1:30                               ` David Woodhouse
2012-12-02  2:40                                 ` Eric Dumazet
2012-12-02  9:31                                   ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1354118982.14302.356.camel@edumazet-glaptop \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dwmw2@infradead.org \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    --cc=saku@ytti.fi \
    --cc=subramanian.vijay@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox