From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wang Jian Date: Mon, 04 Apr 2005 09:10:36 +0000 Subject: Re: [LARTC] new perflow rate control queue Message-Id: <20050404165810.0226.LARK@linux.net.cn> List-Id: References: <20050404152117.6d90635d.lark@linux.net.cn> In-Reply-To: <20050404152117.6d90635d.lark@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Hi Patrick McHardy, HTB + SQF can only achieve part of funcionality. Per flow rate control means per flow bandwidth assurance + bandwidth constraint. When we use HTB + SQF, 1. We can't achieve bandwidth assurance when flow count is higher than expected; this often means we fail to meet the quality requirement. 2. We can't enforce bandwidth constraint when flow count is very low; this often means waste of bandwidth. On Mon, 04 Apr 2005 10:51:15 +0200, Patrick McHardy wrote: > Wang Jian wrote: > > Hi, > > > > One of my customer needs per flow rate control, so I write one. > > > > The code I post here is not finished, but it seems to work as expected. > > > > The kernel patch is agains kernel 2.6.11, the iproute2 patch is against > > iproute2-2.6.11-050314. > > > > I write the code in a hurry to meet deadline. There are many other things > > to do ahead for me. The code is written in 2 days (including read other > > queue's code) and tested for a while to find obvious mistake. Don't be > > suprised when you find many many bugs. > > It looks quite clean, but couldn't the same be achieved with just > providing per-flow fairness and leaving the rate-limiting to an > upper qdisc like HTB or HFSC? > > Regards > Patrick -- lark _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc