netdev - Re: [RFC] iproute2/tc caching proposal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200905072249.27384.denys@visp.net.lb>
Date:	Thu, 7 May 2009 22:49:27 +0300
From:	Denys Fedoryschenko <denys@...p.net.lb>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	Patrick McHardy <kaber@...sh.net>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	netdev@...r.kernel.org
Subject: Re: [RFC] iproute2/tc caching proposal

On Thursday 07 May 2009 22:27:02 Jarek Poplawski wrote:
> Jarek Poplawski wrote, On 05/07/2009 08:44 PM:
> > Do you mean 30 sec. is to short for a change? I don't know these things
> > enough; your idea looks very nice, but I wonder if you tested how it
> > behaves if e.g. after 15k rules some dev goes away which is used in the
> > next 15k?
>
> Hmm... actually, it seems there should be no problem, except less info on
> the
>
> reason of the failure.
Info will be same, completely. Just case with changing interfaces have to be 
handled correctly in any case, in case of batch. It is difficult to explain, 
each person doing his own way shapers. I can explain even, why in my case 
caching is better. And probably all other, properly done shapers for such 
cases.

But for me critical, that when i load shaper, machine is for 10 minutes eating 
dust (cpu utilisation is high, fans turning like hell :-))) ), and some of 
users have bandwidth without restrictions. 30 secs much better, and still 
here is space for improvement.


>
>
> Jarek P.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html