netdev
[Top] [All Lists]

Re: [RFC] batched tc to improve change throughput

To: Thomas Graf <tgraf@xxxxxxx>
Subject: Re: [RFC] batched tc to improve change throughput
From: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Mon, 17 Jan 2005 10:02:16 -0800
Cc: Jamal Hadi Salim <hadi@xxxxxxxxxx>, Patrick McHardy <kaber@xxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20050117152312.GC26856@postel.suug.ch>
Organization: Open Source Development Lab
References: <20050117152312.GC26856@postel.suug.ch>
Sender: netdev-bounce@xxxxxxxxxxx
On Mon, 17 Jan 2005 16:23:12 +0100
Thomas Graf <tgraf@xxxxxxx> 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?

The tc command line processing might leak memory now, or suffer
from expected variable initialization issues.  You may want to run it
with valgrind or other tools to check for that.

-- 
Stephen Hemminger       <shemminger@xxxxxxxx>

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