netdev
[Top] [All Lists]

Re: [RFC] batched tc to improve change throughput

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: [RFC] batched tc to improve change throughput
From: Werner Almesberger <werner@xxxxxxxxxxxxxxx>
Date: Wed, 19 Jan 2005 13:45:38 -0300
Cc: Thomas Graf <tgraf@xxxxxxx>, Patrick McHardy <kaber@xxxxxxxxx>, Stephen Hemminger <shemminger@xxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <1106144009.1047.989.camel@jzny.localdomain>; from hadi@cyberus.ca on Wed, Jan 19, 2005 at 09:13:30AM -0500
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>
Sender: netdev-bounce@xxxxxxxxxxx
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@xxxxxxxxxxxxxxx /
/_http://www.almesberger.net/____________________________________________/

<Prev in Thread] Current Thread [Next in Thread>