Date: Sat, 11 Jun 2005 23:07:21 +0300 From: Vlad GALU <vladgalu@gmail.com> To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: Please review & test this Message-ID: <79722fad050611130734c36979@mail.gmail.com> In-Reply-To: <79722fad0506110228538ee434@mail.gmail.com> References: <79722fad05060914123edd1004@mail.gmail.com> <79722fad050609151068c71c91@mail.gmail.com> <79722fad0506110228538ee434@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/11/05, Vlad GALU <vladgalu@gmail.com> wrote: > On 6/10/05, Vlad GALU <vladgalu@gmail.com> wrote: > > On 6/10/05, Vlad GALU <vladgalu@gmail.com> wrote: > > > As you may all know, the packet classifier in ALTQ is very > > > slow on large numbers of classes, because it stores them linearly, in > > > an array. I rewrote the way classes are stored, replacing the array > > > with a hash table. I tested [1] on a system with about 8000 classes > > > and noticed a remarkable performance difference (the system went from > > > almost unusable to nice & smooth). It breaks the ABI by adding an > > > extra TAILQ_ENTRY member to the HFSC class structure, though. > > > > And also replaces the class array in struct hfsc_if with the hash tab= le. >=20 > Bummer. Increasing the number of classes led to locking the machine > up. Something slipped my eye: the filters are also linearly searched > for. I'll try to do something about them as well and come back with > something. >=20 Duhhh, I need more coffee. I didn't notice the ALTQ3_COMPAT ifdef in the source. Luckily, the patch in my first mail deals with it as well. The classifying is entirely done by pf, so I guess it only depends on how (un)optimized your ruleset is. > > > > > If anyone reviews and tests it, I would be grateful. > > > > > > [1] http://night.rdslink.ro/dudu/altq/altq_hfschash.diff > > > > > > P.S. please keep in mind that I'm not exactly a black belt in kernel > > > programming, so glitches might exist. I would be most happy to hear > > > some suggestions. > > > > > > -- > > > If it's there, and you can see it, it's real. > > > If it's not there, and you can see it, it's virtual. > > > If it's there, and you can't see it, it's transparent. > > > If it's not there, and you can't see it, you erased it. > > > > > > > > > -- > > If it's there, and you can see it, it's real. > > If it's not there, and you can see it, it's virtual. > > If it's there, and you can't see it, it's transparent. > > If it's not there, and you can't see it, you erased it. > > >=20 >=20 > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. >=20 --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79722fad050611130734c36979>