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]

Message-ID: <20090423082052.GA4243@ff.dom.local>
Date:	Thu, 23 Apr 2009 08:20:52 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Jesper Dangaard Brouer <hawk@...u.dk>
Cc:	Radu Rendec <radu.rendec@...s.ro>,
	Denys Fedoryschenko <denys@...p.net.lb>, netdev@...r.kernel.org
Subject: Re: htb parallelism on multi-core platforms

On 22-04-2009 23:29, Jesper Dangaard Brouer wrote:
> 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.

Within a common tree of classes it would a need finer locking to
separate some jobs but considering cache problems I doubt there would
be much gain from such redesigning for smp. On the other hand, a
common tree is necessary if these classes really have to share every
byte, which I doubt. Then we could think of config and maybe tiny
hardware "redesign" (to more qdiscs/roots). So, e.g. using additional
(cheap) NICs and even switch, if possible, looks quite natural way of
spanning. Similar thing (multiple htb qdiscs) should be possible in
the future with one multiqueue NIC too.

There is also an interesting thread "Software receive packet steering"
nearby, but using this for shaping only looks like "less simple":
http://lwn.net/Articles/328339/

> 
>> 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?

BTW, I hope you add filters after classes they point to.

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