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

[Eric Dumazet <dada1@cosmosbay.com>]

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.
> 
>     Benefits:
>      - established connection is now reset if it never makes it to the accept
>      queue
> 
>      - diagnostic state of established matches with the packet traces
>        showing completed handshake
> 
>     - TCP_DEFER_ACCEPT timeouts are expressed in seconds and can now be
>       enforced with reasonable accuracy instead of rounding up to next
>       exponential back-off of syn-ack retry.

This all makes sense Patrick.

Your patch is quite large and difficult to review (for me :) )

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.

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.