All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Dave Taht <dave.taht@gmail.com>,
	"John A. Sullivan III" <jsullivan@opensourcedevel.com>,
	netdev@vger.kernel.org
Subject: Re: netem and hierarchical ingress traffic shaping
Date: Fri, 23 Dec 2011 11:07:49 -0800	[thread overview]
Message-ID: <20111223110749.7a690685@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <1324664907.2915.5.camel@edumazet-laptop>

On Fri, 23 Dec 2011 19:28:27 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Le vendredi 23 décembre 2011 à 18:54 +0100, Dave Taht a écrit :
> 
> > Are there any place where all 48 bytes of cb are used?
> > 
> 
> Yes, but on in qdisc layer.
> 
> struct tcp_skb_cb is known to be 44 bytes (when IPv6 is enabled)
> 
> In qdisc layer, we use a small part of it, for the moment.
> 
> > I wouldn't mind if 'time_to_send' became a separate skb field
> > for a more generic 'time_in_queue'...
> > 
> 
> This wont happen.
> 
> As I posted in an earlier patch, this can be added in "struct
> qdisc_skb_cb"
> 
> 
> 

skb_cb is the dumping ground of the networking layer.
The assumption was that the qdisc could use the skb_cb
for it's own scratchpad. Netem is using it for tagging
packets in the queue. 

So basically, netem, choke, and sfb are incompatible with
each other. This is not that bad, why not add a flag to qdisc
ops to indicate which qdisc are using cb and block user from
trying to do something bogus.

  parent reply	other threads:[~2011-12-23 19:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-18  5:12 netem and hierarchical ingress traffic shaping John A. Sullivan III
2011-12-18 19:55 ` Stephen Hemminger
2011-12-19 16:53   ` John A. Sullivan III
2011-12-23 17:33   ` Eric Dumazet
2011-12-23 17:39     ` Eric Dumazet
2011-12-23 17:54       ` Dave Taht
2011-12-23 18:28         ` Eric Dumazet
2011-12-23 18:54           ` Dave Taht
2011-12-23 19:07           ` Stephen Hemminger [this message]
2011-12-23 19:21             ` Eric Dumazet
2011-12-29  4:26               ` [PATCH net-next] netem: fix classful handling Eric Dumazet
2011-12-29  6:17                 ` Stephen Hemminger
2011-12-29  9:12                   ` Eric Dumazet
2011-12-29 16:52                     ` Hagen Paul Pfeifer
2011-12-29 17:15                       ` Eric Dumazet
2011-12-29 17:43                         ` Hagen Paul Pfeifer
2011-12-29 18:10                           ` Eric Dumazet
2011-12-29 18:25                             ` Hagen Paul Pfeifer
2011-12-29 18:31                               ` Stephen Hemminger
2011-12-29 18:36                               ` Eric Dumazet
2011-12-30 22:12                     ` David Miller
2011-12-23 19:36             ` netem and hierarchical ingress traffic shaping David Miller

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=20111223110749.7a690685@nehalam.linuxnetplumber.net \
    --to=shemminger@vyatta.com \
    --cc=dave.taht@gmail.com \
    --cc=eric.dumazet@gmail.com \
    --cc=jsullivan@opensourcedevel.com \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.