netdev - Re: [PATCH] IPVS: Allow boot time change of hash size.

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: <1228338713.24149.10.camel@ernie.internal.graemef.net>
Date:	Wed, 03 Dec 2008 21:11:53 +0000
From:	Graeme Fowler <graeme@...emef.net>
To:	"Catalin(ux) M. BOIE" <catab@...edromix.ro>
Cc:	David Miller <davem@...emloft.net>, jmack@...d.net,
	netdev@...r.kernel.org, lvs-devel@...r.kernel.org
Subject: Re: [PATCH] IPVS: Allow boot time change of hash size.

On Tue, 2008-12-02 at 16:16 -0700, Catalin(ux) M. BOIE wrote:
> I have a need, I didn't wake up some day and I dreamed to change this.
> I have a gateway with LVS and I have 4 web servers behind.
> I saw the help text at that option and I saw that I could raise the limit.

OK, let's ask the same question a different way, after going a little
further into your posting:

> I was looking for anything that could get me past of 88.000 request per
> seconds.
> The help text told me to raise that value if I have big number of
> connections. I just needed an easy way to test.

OK, so from here:

http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.operation.html#hash_table

and onward... have you read all of that? It explains how the hash table
size has been developed over the years, and everything that has changed
with and relating to it.

To pull out an example, a hash table size of 21 bits does not give a
connection limit of 2^21 entries, since each part of the hash is a
linked list which contains multiple entries, up to the RAM limit in the
server.

In the HOWTO, the example given shows that for a traffic pattern with 4
seconds session coherence and 1/8th of the traffic hitting the director
being a SYN for the available config *appears* to require 2^21 bits.
However, because each bit of the hash is a linked list, using 17 bits
gets 16 entries in each list - this is not a problem, as it takes the
CPU no time at all to search 16 entries.

What you need to do for us, please, is to demonstrate that your problem
(not exceeding 88k RPS) is categorically something to do with lookups in
the hash table. I suspect (although I've been wrong before) that your
problem is probably to do with the number of interrupts your hardware
can process. There have been many posts of this type on lvs-users
recently - search the archives to see what the solutions were.

We're trying to help, but the collective wisdom here is that the hash
table size is not the cause of your problem *which you haven't yet
described fully*.

Graeme

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