On Wed, 2015-11-11 at 09:05 -0800, Tom Herbert wrote: > On Tue, Nov 10, 2015 at 10:19 PM, Eric Dumazet <[email protected]> wrote: > > On Tue, 2015-11-10 at 21:41 -0800, Tom Herbert wrote: > >> Tolga, are you still planning to respin this patch (when tree opens?) > > > > I was planning to add an union on skc_tx_queue_mapping and > > sk_max_ack_backlog, so that adding a check on sk_max_ack_backlog in > > listener lookup would not add an additional cache line miss. > > > > This would remove false sharing because sk_ack_backlog is often dirtied > > when a socket is added into accept queue. > > > That's sounds like good fixes, but my question was more about the > problem originally described by Tolga where we are transitioning > processing for a listener port from one process to another. I think > the conclusion in this thread was to modify the code so that > listen(fd, 0) would stop new connections from being assigned to a > socket (as opposed to explicit SO_REUSEPORT_LISTEN_OFF option). Does > this still seem reasonable?
Actually listen(fd, 0) is not going to work well : For request_sock that were created (by incoming SYN packet) before this listen(fd, 0) call, the 3rd packet (ACK coming from client) would not be able to create a child attached to this listener. sk_acceptq_is_full() test in tcp_v4_syn_recv_sock() would simply drop the thing. I was mainly objecting adding yet another socket option. Maybe setsockopt(... SO_REUSEPORT, &off, sizeof(off)) could detect the condition automatically ? (I am not sure current behavior of setting sk->sk_reuseport = valbool; is correct if valbool==0 and current sk_reuseport is 1) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
