netdev - Re: [PATCH] Stochastic Fair Blue queue discipline

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 for Android: free password hash cracker in your pocket

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

Message-ID: <47FCE826.2030106@trash.net>
Date:	Wed, 09 Apr 2008 18:00:38 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Juliusz Chroboczek <Juliusz.Chroboczek@....jussieu.fr>
CC:	Andi Kleen <andi@...stfloor.org>, netdev@...r.kernel.org
Subject: Re: [PATCH] Stochastic Fair Blue queue discipline

Juliusz Chroboczek wrote:
>>>> I'd suggest to use the flow classifier for this. For simplicity
>>>> you could attach a default classifier that uses the same keys as
>>>> this one.
> 
>>> I'm not sure I know what you're speaking about.  Could you please
>>> point me at code somewhere?
> 
>> Check out a recent tree (either Linus' current tree or ideally
>> the net-2.6.26.git tree from
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.26.git
>>
>> and look at net/sched/cls_flow.c and the recent changes to
>> net/sched/sch_sfq.c for external classifiers.
> 
> Thanks for the pointer.  Unfortunately, it will need some changes to
> work with sfb -- since we do double-buffering, we need some overlap
> between the old and new classifiers when we choose to reclassify.  I'm
> not quite sure how to do that.

You mean for perturbation? Yes, thats something not currently
supported. I'd suggest to ignore this for now, I intend
to add support, just need to figure out a way to reliably
kill the timer on cleanup (can't use del_timer_sync since
we're holding a lock). Shouldn't be that hard ...

> Other than that, it will require some changes to sfb (which currently
> assumes we can get an arbitrary amount of hash data for a single
> packet, while the classifiers only give 32 bits), but these changes
> are a good thing -- 32 bits should be enough.

Actually its only (max) 16 bits, the qdisc handle is always
encoded in the upper 16 bits. If you need more you could
combine it with other data. I recall seeing a paper about bloom
filters that analyzed the effectiveness of this compared to
perfect hashing, they concluded that the increase in false
positives is negligible.

I'll see if I can find it again in case you're interested.

> Would you have an example of how this stuff is configured from
> user-space?

I'm using this for per-dst hashing to 1024 classes
(1400:1 - 1400:1025).

tc filter add dev eth0 protocol ip pref 1 parent 1400: handle 1 \
         flow hash keys dst divisor 1024 

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