Thread (9 messages) flat view 9 messages, 3 authors, 2004-12-01

Re: [PATCH] tcp: efficient port randomisation

From: Stephen Hemminger <hidden>
Date: 2004-11-01 17:20:27

On Mon, 1 Nov 2004 11:58:23 +0200
Michael Vittrup Larsen [off-list ref] wrote:
On Friday 29 October 2004 19:28, Stephen Hemminger wrote:
quoted
Provide port randomization for incoming connections using variation of
existing sequence number hash. Replace tcp_portalloc_lock and
tcp_port_rover with atomic operation to allow better parallelism.

This is based on
http://www.ietf.org/internet-drafts/draft-larsen-tsvwg-port-randomisation-0
0.txt (with confirmation of of no IPR issues).
I have looked through this, and have a few comments:

* It is probably a good strategy to set 'tcp_rover_next' such that
  the next search is resumed from the previous port found to be free.
  (similar to the old algorithm).  I don't see this in your patch,
  but of course I could have missed it.
It was intentional since it would require holding a lock around the search. The tradeoff
is better SMP performance in the sparsely filled port space (more typical) vs.
better UP performance in the case of a mostly full port space.

* connect_port_offset() does not (at least from an algorithm point
  of view) need to return an u32, an u16 is sufficient.
If it is truncated to u16, then compiler has to take extra effort to truncate
is unnecessary given later  modulo operation.
Michael Larsen
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help