netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Werner Almesberger <werner@almesberger.net>
To: jamal <hadi@cyberus.ca>
Cc: Thomas Graf <tgraf@suug.ch>, Patrick McHardy <kaber@trash.net>,
	Stephen Hemminger <shemminger@osdl.org>,
	netdev@oss.sgi.com
Subject: Re: [RFC] batched tc to improve change throughput
Date: Wed, 19 Jan 2005 13:45:38 -0300	[thread overview]
Message-ID: <20050119134538.J15303@almesberger.net> (raw)
In-Reply-To: <1106144009.1047.989.camel@jzny.localdomain>; from hadi@cyberus.ca on Wed, Jan 19, 2005 at 09:13:30AM -0500

jamal wrote:
> As Lennert was saying, puke whatever the kernel said and allow for
> rollback. i.e undo the first one if it succeeded for example.

How about this: you have a shadow configuration tree on each ingress
and egress point (i.e. two per interface). An update generates the
shadow tree. If done, you commit the shadow tree to become the new
config, and then you can quietly dismantle the old config. If you
didn't like the changes, you kill the shadow tree, without committing
it.

To preserve queue content and element state (e.g. policer state),
you'd also have to have a means to tell where to take things from,
e.g. "shadow" qdisc X inherits the packets from "real" qdisc Y. All
this could be checked for consistency at setup time.

There are of course limitations, e.g. when you merge or split flows.

As an optimization, you could have some "lazy copy": instead of
creating new qdisc "inheriting" from some other, you just move it
from the old to the new tree.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina     werner@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

  parent reply	other threads:[~2005-01-19 16:45 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-17 15:23 [RFC] batched tc to improve change throughput Thomas Graf
2005-01-17 15:45 ` jamal
2005-01-17 16:05   ` Thomas Graf
2005-01-17 16:36     ` jamal
2005-01-17 16:56       ` Thomas Graf
2005-01-17 22:49         ` jamal
2005-01-18 13:44           ` Thomas Graf
2005-01-18 14:29             ` jamal
2005-01-18 14:36               ` Lennert Buytenhek
2005-01-18 14:43                 ` jamal
2005-01-18 15:07                   ` Thomas Graf
2005-01-18 15:20                   ` Lennert Buytenhek
2005-01-19 14:24                     ` jamal
2005-01-18 14:58               ` Thomas Graf
2005-01-18 15:23                 ` Lennert Buytenhek
2005-01-19 14:13                 ` jamal
2005-01-19 14:36                   ` Thomas Graf
2005-01-19 16:45                   ` Werner Almesberger [this message]
2005-01-19 16:54                   ` Thomas Graf
2005-01-20 14:42                     ` jamal
2005-01-20 15:35                       ` Thomas Graf
2005-01-20 17:06                         ` Stephen Hemminger
2005-01-20 17:19                           ` Thomas Graf
2005-01-24 14:13                         ` jamal
2005-01-24 15:06                           ` Thomas Graf
2005-01-26 13:48                             ` jamal
2005-01-26 14:35                               ` Thomas Graf
2005-02-11 15:07                               ` Dan Siemon
2005-02-12 13:45                                 ` jamal
2005-02-12 14:29                                   ` Thomas Graf
2005-02-12 22:07                                   ` Dan Siemon
2005-02-12 22:32                                     ` Thomas Graf
2005-02-14  0:23                                       ` Dan Siemon
2005-02-14 14:27                                         ` Thomas Graf
2005-02-15 20:28                                           ` Dan Siemon
2005-02-15 20:47                                             ` Thomas Graf
2005-02-22 21:40                                               ` Dan Siemon
2005-02-22 23:15                                                 ` Thomas Graf
2005-01-18 15:07               ` Werner Almesberger
2005-01-19 14:08                 ` Thomas Graf
2005-01-19 16:33                   ` Werner Almesberger
2005-01-19 17:22                     ` Thomas Graf
2005-01-17 18:00 ` Stephen Hemminger
2005-01-17 18:02 ` Stephen Hemminger

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=20050119134538.J15303@almesberger.net \
    --to=werner@almesberger.net \
    --cc=hadi@cyberus.ca \
    --cc=kaber@trash.net \
    --cc=netdev@oss.sgi.com \
    --cc=shemminger@osdl.org \
    --cc=tgraf@suug.ch \
    /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;
as well as URLs for NNTP newsgroup(s).