[Click] dynamic changes to a click configuration

[Eddie Kohler]

Mike,

You do know that you can install a new configuration without killing 
Click, right?

And the "hotswap" feature (click-install -h) will install a new 
configuration without losing any packets in Queue and FromDevice 
elements, assuming the new & old elements have the same name.  There may 
be a performance hiccup, but only small, and you should measure to see.

We've considered dynamically adding elements for awhile (and may get to 
it soon), but in practice, hotswapping is good enough for many people, 
including others on this list.

Eddie


Mike Wilson wrote:
> Hi, all,
> 
>  	I've used click for a number of fairly typical projects - IP 
> routers, tracking latency and throughput, etc.  Now I've got a project 
> that I don't think fits the click model.  I certainly don't see a good
> way to do it, but I wanted to double-check with the rest of the click 
> community before I abandoned click as an option.
> 
>  	Picture a router with a potentially unlimited number of virtual 
> interfaces of varying forms of encapsulation.  What I need is a way to
> dynamically add and remove interfaces, and change the encapsulation of 
> virtual interfaces on this router.  It's enough that these virtual 
> interfaces only exist within click, but I've got nothing against them
> also being OS-level virtual interfaces, too.  The protocols over the
> virtual interfaces are not necessarily all IP.
>  	For any static configuration, click is simple and easy.  I'd have 
> something like this, for a 2-interface version:
> 
> FromDevice("eth0") -> Classifier(...)[0] -> Strip(...) -> ... ;
>                        Classifier(...)[1] -> Strip(...) -> ... ;
> 
>  	Now if I need to add a new interface, I can't because the number 
> of Classifier outputs are static.  I suppose I could use a classifier with 
> a huge number of output and only map to the ones in use, then change the 
> filters on the fly.  Classifier doesn't do this, but the IPRouteTable 
> does, and I'm sure some of the other elements do.  However, they *don't* 
> allow me to change the decapsulation in the next stage.
> 
>  	A heavy-handed approach would be to re-write the configuration 
> file and kill/restart click.  Unfortunately, this loses everything in the 
> Queues.  I could dummy out a kludged configuration where there are 
> multiple click configs and the queuing is all in separate configurations, 
> but this strikes me as increasingly ugly.  I think I'd potentially lose a 
> packet in the non-queuing configurations, too.
> 
>  	The next approach is to write my own elements that just track
> all of the virtual interfaces internally, applying the appropriate 
> decapsulation and processing for each one.  I think I'd end up embodying 
> most of the functionality from a lot of other elements in my new element, 
> losing the major benefit of click -- having it all pre-written and 
> tested.
> 
>  	Is this problem just ill-suited for the click model, or is there 
> an option I'm missing?  The ideal would be to change the configuration on 
> the fly by adding new elements, changing the intial Classifier to add the 
> new element chain (and probably the queues at the far end to accept 
> packets from it).  I don't think this is even in the click model, is it?
> 
> -Mike Wilson
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click