Re: RFC [PATCH 3/3] TCP_DEFER_ACCEPT updates: more accurate timers and resets

[Patrick McManus <mcmanus@ducksong.com>]

On Sat, 2008-03-01 at 11:53 +0100, Eric Dumazet wrote:
> Patrick McManus a écrit :
> > Signed-off-by: Patrick McManus <mcmanus@ducksong.com>
> > 
> >   Change TCP_DEFER_ACCEPT implementation so that it transitions a
> >     connection to ESTABLISHED after handshake is complete instead of
> >     leaving it in SYN-RECV until some data arrvies. Place connection in
> >     accept queue when first data packet arrives from slow path.
> >
> This all makes sense Patrick.
> 
> Your patch is quite large and difficult to review (for me :) )
> 

Eric, thanks for the feedback!

> 1) Adding "struct tcp_deferred_accept_info" on "struct tcp_sock" (24 bytes on 
> 64 bit arches) is a rather high cost to pay for an obscure TCP_DEFER_ACCEPT.
> 
> But then, many "struct tcp_sock" fields are used only at socket establishment.
> 

It occurs to me the child socket pointer in that struct is superfulous,
so I can cut it down to two ptrs instead of three.. I'll include that in
a respin - and as you point out struct tcp_sock is already full of stuff
that is really only used once.

> 2) About MAX_TCP_ACCEPT_DEFERRED test in do_tcp_setsockopt(), I am not sure we 
> can return -EINVAL.
> 

> setsockopt(TCP_DEFER_ACCEPT, 100000) is a hint given by application, and could 
> be mapped to setsockopt(TCP_DEFER_ACCEPT, 65535) silently.

good point, I agree. I'll include that change in the respin too.


-Patrick