cvs commit: src/sys/netinet in_pcb.c tcp_subr.c tcp_timer.c tcp_var.h

[Gleb Smirnoff]

On Mon, Sep 11, 2006 at 01:21:14AM -0500, Mike Silbersack wrote:
M> Ok, I started looking through the mess that is in_pcb.c, and I came up 
M> with a simpler idea than trying to improve upon my old heuristic.
M> 
M> What if we just build upon what Gleb did in revision 1.256, and change the 
M> size of the tcptw zone?  Instead of scaling it to maxsockets / 5, let's 
M> scale it to max((ipport_lastauto - ipport_firstauto)/2, 500).  We'll have 
M> to rescale it whenever the port ranges are changed, but those sysctls are 
M> already handled by a function, so it'll be easy.

The UMA zone can't be made smaller than it is, while IP port ranges
can vary in both directions.

M> This means that we'll be keeping around fewer time_wait sockets than we do 
M> at present, but I don't think that's a big problem for anyone.  On the 
M> positive side, it means that time_wait sockets can't starve out ephemeral 
M> ports unless you have more than 50% active connections.
M> 
M> One slightly more complex solution would be to use one tcptw bucket for 
M> connections with local ports >= 1024 and a seperate bucket for connections 
M> with local ports < 1024.  Assuming that our front end web proxy answers on 
M> ports < 1024, that would ensure that we keep one pool of time_wait sockets 
M> for our connections from clients and another pool for our connections to 
M> the backend web servers.  I guess that would be slightly more "correct".
M> 
M> What do you guys think?

I think that your original commit should be rethought. It should free one
tcptw entry, in a case of absolute match, and return NULL. Do not jump
up and go on into cycle again.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE