From mboxrd@z Thu Jan 1 00:00:00 1970 From: jamal Subject: Re: [RFC] batched tc to improve change throughput Date: 17 Jan 2005 10:45:11 -0500 Message-ID: <1105976711.1078.1.camel@jzny.localdomain> References: <20050117152312.GC26856@postel.suug.ch> Reply-To: hadi@cyberus.ca Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Patrick McHardy , Stephen Hemminger , netdev@oss.sgi.com Return-path: To: Thomas Graf In-Reply-To: <20050117152312.GC26856@postel.suug.ch> Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org You dont like the -batch option to tc? ;-> cheers, jamal On Mon, 2005-01-17 at 10:23, Thomas Graf wrote: > While collecting performance numbers for the ematch changes > I realized that the throughput of changes per second is > almost only limited by the cost of starting the tc binary > over and over. In order to improve this, batching of commands > is required. My plan to do so is quite simple, introduce > a new flag -f which puts tc into batched mode and makes > it read commands from stdin. A bison based parser splits > things into tokens, the grammer would be quite easy: > > INPUT ::= { /* empty */ | CMDS } > CMDS ::= { CMD | CMD ';' CMDS } > CMD ::= ARGS > ARGS ::= { STRING | STRING ARGS } > > The lexical part can be made to ignore c-syle and > shell-style comments, i.e. > > --- > #!/sbin/tc -f > > /* some comments here */ > qdisc add .. > class ... > > # shell like comments also possible > filter add ... basic match ... > --- > > Of course this loses ability to use shell features like > variables and loops and it's probably not worth trying > to emulate things. One can always generate these tc scripts > with the help of other tools like m4, you name it. > > This could also be applied to ip of course. > > Thoughts? > >