netdev - Re: [1/1 take 2] Unified socket storage. (with small bench).

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: <20070509.030200.123972145.davem@davemloft.net>
Date:	Wed, 09 May 2007 03:02:00 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	johnpol@....mipt.ru
Cc:	netdev@...r.kernel.org
Subject: Re: [1/1 take 2] Unified socket storage. (with small bench).

From: Evgeniy Polyakov <johnpol@....mipt.ru>
Date: Wed, 9 May 2007 13:57:40 +0400

> That is only because we have very different way of working with udp.
> In udp hash table we can have multiple sockets bound to different ip
> addresses, but with the same port, so it will be placed into the same
> hash chain. With trie each socket will have differnet key, since
> addresses are different (or bound device number), so it automatically
> fixes problem with broken hash for udp (which is a bit fixed with
> extended hashing).

Yes it is power of trie.

So connection rates are interesting, but what about raw lookup
performance?  Last time this topic came up you went into some
cave when you looked at the trie lookup assembly and compared
it to hash. :)

It does make more memory references than hash by definition, and we
need to figure out whether that matters enough or not.
-
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