| 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/____________________________________________/ |
| Previous by Date: | Re: [RFC] batched tc to improve change throughput, Werner Almesberger |
|---|---|
| Next by Date: | Re: [RFC] batched tc to improve change throughput, Thomas Graf |
| Previous by Thread: | Re: [RFC] batched tc to improve change throughput, Thomas Graf |
| Next by Thread: | Re: [RFC] batched tc to improve change throughput, Thomas Graf |
| Indexes: | [Date] [Thread] [Top] [All Lists] |