From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: Compare length of req sock queue with sk_max_ack_backlog Date: Thu, 01 Feb 2018 06:00:07 -0800 Message-ID: <1517493607.3715.117.camel@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Linux Kernel Network Developers To: Tonghao Zhang , Eric Dumazet Return-path: Received: from mail-pg0-f67.google.com ([74.125.83.67]:39280 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751557AbeBAOAJ (ORCPT ); Thu, 1 Feb 2018 09:00:09 -0500 Received: by mail-pg0-f67.google.com with SMTP id w17so12426857pgv.6 for ; Thu, 01 Feb 2018 06:00:09 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 2018-02-01 at 20:34 +0800, Tonghao Zhang wrote: > Hi Eric > One question for you, In the patch ef547f2ac16 ("tcp: remove > max_qlen_log"), why we compared the length of req sock queue with > sk_max_ack_backlog. If we remove the max_qlen_log, we should check the > length of req sock queue with tcp_max_syn_backlog, right ? > > With this patch, the option "/proc/sys/net/ipv4/tcp_max_syn_backlog" > will be unsed anymore, right ? Not right. Please "git grep -n sysctl_max_syn_backlog" to convince it is still used. > > I hope we should > 1. Add a variate in sock struct, such as sk_max_syn_backlog. Then req > sock queue and accept sock queue can control their max value. When we > create the sock, we can store the tcp_max_syn_backlog value to > sk_max_syn_backlog. > There is a single /proc/sys/net/ipv4/tcp_max_syn_backlog value shared by all sockets of a given network namespace. But you can have thousands of TCP listeners, each of them having a distinct listen() backlog > 2. Update the backlog, we can update it via ioctl. No need to add an ugly ioctl. Simply call listen() again with another backlog value.