> per CPU ids are simple (just seed with a different secret).
IPv4 ID space is too small to split it even more.
> The secure RND can run with a few cache lines, the AVL inetpeer
> code needs a potentially unlimited number of cache lines.
Zero in 99.9% of cases 8). The state is help, but is used
only in exceptional cases.
> (my first vote for the per-dst counter was based
> on the assumptions that it is free because the routing cache can be
> used).
Next time think _before_ voting rather then after the work is done. 8)
Actually, there are no differences from performance viewpoint.
Consider peer state as part of destination cache, which sits out
of hash table and eats less memory.
AVL just provides more or less reasonable way to access them
for reasonable time, _EASIER_ than with hash tables.
> For what else would you want to use the inetpeer cache?
For all the things, which require keeping state for finite
time. F.e. for timewait truncation.
> The assumption that it can hold information for all peers looks
> broken to me. Every attacker can pollute it enough to fill all
> available memory (so you only raise the limit over the routing cache
> hash a bit, not fix it)
Not a bit! Andi, seems you do not understand the problem.
During tests even on my poor hardware I see >~100000 timewait
buckets. Just calculate conn/sec rate of your machine, multiply
it with MSL and you will have this number for your hardware.
And shrug extrapolating the number for Gigabit interfaces
and faster CPUs.
Now look at the situation and compare it with peer table:
- TW buckets are fully useless in 99.9(9)% of cases.
- We must hold them for finite time.
What do I want to say? I want to say that holding state _ONLY_ to hold it
is not a new problem. And not depending on our preferences, we have
to solve this problem, which will be more and more painful,
when power of servers grow.
BTW unlike you I voted for openbsd-like solution from the very beginning. 8)
But I have to recognize that peer table is more robust and more promising.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/