Received: with ECARTIS (v1.0.0; list netdev); Wed, 19 Jan 2005 08:45:53 -0800 (PST) Received: from host.almesberger.net (almesberger.net [63.105.73.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0JGjmGX028673 for ; Wed, 19 Jan 2005 08:45:49 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.12.8/8.9.3) with ESMTP id j0JGjeTO000338; Wed, 19 Jan 2005 08:45:42 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id j0JGjcS20174; Wed, 19 Jan 2005 13:45:38 -0300 Date: Wed, 19 Jan 2005 13:45:38 -0300 From: Werner Almesberger To: jamal Cc: Thomas Graf , Patrick McHardy , Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [RFC] batched tc to improve change throughput Message-ID: <20050119134538.J15303@almesberger.net> References: <20050117152312.GC26856@postel.suug.ch> <1105976711.1078.1.camel@jzny.localdomain> <20050117160539.GD26856@postel.suug.ch> <1105979807.1078.16.camel@jzny.localdomain> <20050117165626.GE26856@postel.suug.ch> <1106002197.1046.19.camel@jzny.localdomain> <20050118134406.GR26856@postel.suug.ch> <1106058592.1035.95.camel@jzny.localdomain> <20050118145830.GS26856@postel.suug.ch> <1106144009.1047.989.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1106144009.1047.989.camel@jzny.localdomain>; from hadi@cyberus.ca on Wed, Jan 19, 2005 at 09:13:30AM -0500 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev 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/____________________________________________/