netdev - Re: htb parallelism on multi-core platforms

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]

Date:	Wed, 22 Apr 2009 23:29:32 +0200 (CEST)
From:	Jesper Dangaard Brouer <hawk@...u.dk>
To:	Radu Rendec <radu.rendec@...s.ro>
Cc:	Jarek Poplawski <jarkao2@...il.com>,
	Denys Fedoryschenko <denys@...p.net.lb>, netdev@...r.kernel.org
Subject: Re: htb parallelism on multi-core platforms

On Wed, 22 Apr 2009, Radu Rendec wrote:

> Thanks for the hints! As far as I understand, HFSC is also implemented
> as a queue discipline (like HTB), so I guess it suffers from the same
> design limitations (doesn't span across multiple CPUs). Is this
> assumption correct?

Yes.

> As for htb_hysteresis I actually haven't tried it. Although it is
> definitely worth a try (especially if the average traffic grows), I
> don't think it can compensate multithreading / parallel execution.

Its runtime adjustable, so its easy to try out.

  via /sys/module/sch_htb/parameters/htb_hysteresis


> At least half of a packet processing time is consumed by classification 
> (although I am using hashes).

The HTB classify hash has a scalability issue in kernels below 2.6.26. 
Patrick McHardy fixes that up in 2.6.26.  What kernel version are you 
using?

Could you explain how you do classification? And perhaps outline where you 
possible scalability issue is located?

If you are interested how I do scalable classification, see my 
presentation from Netfilter Workshop 2008:

  http://nfws.inl.fr/en/?p=115
  http://www.netoptimizer.dk/presentations/nfsw2008/Jesper-Brouer_Large-iptables-rulesets.pdf


> I guess htb_hysteresis only affects the actual shaping (which takes 
> place after the packet is classified).

Yes, htb_hysteresis basically is a hack to allow extra bursts... we 
actually considered removing it completely...

Hilsen
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
--
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