[{"id":1758078,"web_url":"http://patchwork.ozlabs.org/comment/1758078/","msgid":"","list_archive_url":null,"date":"2017-08-26T18:56:05","subject":"Re: UDP sockets oddities","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 08/26/2017 05:47 AM, Eric Dumazet wrote:\n> On Fri, 2017-08-25 at 21:19 -0700, David Miller wrote:\n> \n>> Agreed, but the ARP resolution queue really needs to scale it's backlog\n>> to the physical technology it is attached to.\n> Yes, last time (in 2011) we increased the old limit of 3 packets :/\n> \n> We probably should match sysctl_wmem_max so that a single socket\n> provider would hit its sk_sndbuf limit\n\nBefore:\n/proc/sys/net/ipv4/neigh/eth0/unres_qlen:34\n/proc/sys/net/ipv4/neigh/eth0/unres_qlen_bytes:65536\n/proc/sys/net/ipv4/neigh/gphy/unres_qlen:34\n/proc/sys/net/ipv4/neigh/gphy/unres_qlen_bytes:65536\n\nAfter:\n/proc/sys/net/ipv4/neigh/eth0/unres_qlen:106\n/proc/sys/net/ipv4/neigh/eth0/unres_qlen_bytes:229376\n/proc/sys/net/ipv4/neigh/gphy/unres_qlen:106\n/proc/sys/net/ipv4/neigh/gphy/unres_qlen_bytes:229376\n\nand this does help a lot with the test case reported over an hour, only\n2 packets lost:\n\n# perf record -a -g -e skb:kfree_skb iperf -c 192.168.1.23 -b 900M -t\n3600 -u\n------------------------------------------------------------\nClient connecting to 192.168.1.23, UDP port 5001\nSending 1470 byte datagrams, IPG target: 13.07 us (kalman adjust)\nUDP buffer size: 224 KByte (default)\n------------------------------------------------------------\n[ 4] local 192.168.1.66 port 48209 connected with 192.168.1.23 port 5001\nwrite failed: Invalid argument\n[ ID] Interval Transfer Bandwidth\n[ 4] 0.0-404.9 sec 4.51 GBytes 95.7 Mbits/sec\n[ 4] Sent 3294727 datagrams\n[ 4] Server Report:\n[ 4] 0.0-405.1 sec 4.51 GBytes 95.6 Mbits/sec 14.979 ms\n2/3294728 (6.1e-05%)\n\nThanks Eric!\n\n> \n> Something like :\n> \n> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt\n> index 6b0bc0f715346a097a6df46e2ba2771359abcd23..7777dceb78107c0019fb39d5b69be1959005b78e 100644\n> --- a/Documentation/networking/ip-sysctl.txt\n> +++ b/Documentation/networking/ip-sysctl.txt\n> @@ -109,7 +109,8 @@ neigh/default/unres_qlen_bytes - INTEGER\n> \tqueued for each\tunresolved address by other network layers.\n> \t(added in linux 3.3)\n> \tSetting negative value is meaningless and will return error.\n> -\tDefault: 65536 Bytes(64KB)\n> +\tDefault: SK_WMEM_MAX, enough to store 256 packets of medium size\n> +\t\t (less than 256 bytes per packet)\n> \n> neigh/default/unres_qlen - INTEGER\n> \tThe maximum number of packets which may be queued for each\n> diff --git a/include/net/sock.h b/include/net/sock.h\n> index 1c2912d433e81b10f3fdc87bcfcbb091570edc03..03a362568357acc7278a318423dd3873103f90ca 100644\n> --- a/include/net/sock.h\n> +++ b/include/net/sock.h\n> @@ -2368,6 +2368,16 @@ bool sk_net_capable(const struct sock *sk, int cap);\n> \n> void sk_get_meminfo(const struct sock *sk, u32 *meminfo);\n> \n> +/* Take into consideration the size of the struct sk_buff overhead in the\n> + * determination of these values, since that is non-constant across\n> + * platforms. This makes socket queueing behavior and performance\n> + * not depend upon such differences.\n> + */\n> +#define _SK_MEM_PACKETS\t\t256\n> +#define _SK_MEM_OVERHEAD\tSKB_TRUESIZE(256)\n> +#define SK_WMEM_MAX\t\t(_SK_MEM_OVERHEAD * _SK_MEM_PACKETS)\n> +#define SK_RMEM_MAX\t\t(_SK_MEM_OVERHEAD * _SK_MEM_PACKETS)\n> +\n> extern __u32 sysctl_wmem_max;\n> extern __u32 sysctl_rmem_max;\n> \n> diff --git a/net/core/sock.c b/net/core/sock.c\n> index dfdd14cac775e9bfcee0085ee32ffcd0ab28b67b..9b7b6bbb2a23e7652a1f34a305f29d49de00bc8c 100644\n> --- a/net/core/sock.c\n> +++ b/net/core/sock.c\n> @@ -307,16 +307,6 @@ static struct lock_class_key af_wlock_keys[AF_MAX];\n> static struct lock_class_key af_elock_keys[AF_MAX];\n> static struct lock_class_key af_kern_callback_keys[AF_MAX];\n> \n> -/* Take into consideration the size of the struct sk_buff overhead in the\n> - * determination of these values, since that is non-constant across\n> - * platforms. This makes socket queueing behavior and performance\n> - * not depend upon such differences.\n> - */\n> -#define _SK_MEM_PACKETS\t\t256\n> -#define _SK_MEM_OVERHEAD\tSKB_TRUESIZE(256)\n> -#define SK_WMEM_MAX\t\t(_SK_MEM_OVERHEAD * _SK_MEM_PACKETS)\n> -#define SK_RMEM_MAX\t\t(_SK_MEM_OVERHEAD * _SK_MEM_PACKETS)\n> -\n> /* Run time adjustable parameters. */\n> __u32 sysctl_wmem_max __read_mostly = SK_WMEM_MAX;\n> EXPORT_SYMBOL(sysctl_wmem_max);\n> diff --git a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c\n> index 21dedf6fd0f76dec22b2b3685beb89cfefea7ded..22bf0b95d6edc3c27ef3a99d27cb70a1551e3e0e 100644\n> --- a/net/decnet/dn_neigh.c\n> +++ b/net/decnet/dn_neigh.c\n> @@ -94,7 +94,7 @@ struct neigh_table dn_neigh_table = {\n> \t\t\t[NEIGH_VAR_BASE_REACHABLE_TIME] = 30 * HZ,\n> \t\t\t[NEIGH_VAR_DELAY_PROBE_TIME] = 5 * HZ,\n> \t\t\t[NEIGH_VAR_GC_STALETIME] = 60 * HZ,\n> -\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = 64*1024,\n> +\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = SK_WMEM_MAX,\n> \t\t\t[NEIGH_VAR_PROXY_QLEN] = 0,\n> \t\t\t[NEIGH_VAR_ANYCAST_DELAY] = 0,\n> \t\t\t[NEIGH_VAR_PROXY_DELAY] = 0,\n> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c\n> index 8b52179ddc6e54eabf6d3c2ed0132083228680bb..7c45b8896709815c5dde5972fd57cb5c3bcb2648 100644\n> --- a/net/ipv4/arp.c\n> +++ b/net/ipv4/arp.c\n> @@ -171,7 +171,7 @@ struct neigh_table arp_tbl = {\n> \t\t\t[NEIGH_VAR_BASE_REACHABLE_TIME] = 30 * HZ,\n> \t\t\t[NEIGH_VAR_DELAY_PROBE_TIME] = 5 * HZ,\n> \t\t\t[NEIGH_VAR_GC_STALETIME] = 60 * HZ,\n> -\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = 64 * 1024,\n> +\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = SK_WMEM_MAX,\n> \t\t\t[NEIGH_VAR_PROXY_QLEN] = 64,\n> \t\t\t[NEIGH_VAR_ANYCAST_DELAY] = 1 * HZ,\n> \t\t\t[NEIGH_VAR_PROXY_DELAY]\t= (8 * HZ) / 10,\n> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c\n> index 5e338eb89509b1df6ebd060f8bd19fcb4b86fe05..266a530414d7be4f1e7be922e465bbab46f7cbac 100644\n> --- a/net/ipv6/ndisc.c\n> +++ b/net/ipv6/ndisc.c\n> @@ -127,7 +127,7 @@ struct neigh_table nd_tbl = {\n> \t\t\t[NEIGH_VAR_BASE_REACHABLE_TIME] = ND_REACHABLE_TIME,\n> \t\t\t[NEIGH_VAR_DELAY_PROBE_TIME] = 5 * HZ,\n> \t\t\t[NEIGH_VAR_GC_STALETIME] = 60 * HZ,\n> -\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = 64 * 1024,\n> +\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = SK_WMEM_MAX,\n> \t\t\t[NEIGH_VAR_PROXY_QLEN] = 64,\n> \t\t\t[NEIGH_VAR_ANYCAST_DELAY] = 1 * HZ,\n> \t\t\t[NEIGH_VAR_PROXY_DELAY] = (8 * HZ) / 10,\n> \n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"D4VFRgUM\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xfnLV3Y0Rz9sN7\n\tfor ;\n\tSun, 27 Aug 2017 04:56:18 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751115AbdHZS4L (ORCPT );\n\tSat, 26 Aug 2017 14:56:11 -0400","from mail-oi0-f67.google.com ([209.85.218.67]:32807 \"EHLO\n\tmail-oi0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751092AbdHZS4K (ORCPT\n\t); Sat, 26 Aug 2017 14:56:10 -0400","by mail-oi0-f67.google.com with SMTP id u206so863668oif.0\n\tfor ; Sat, 26 Aug 2017 11:56:10 -0700 (PDT)","from ?IPv6:2001:470:d:73f:11b9:dd98:ec7a:4f61?\n\t([2001:470:d:73f:11b9:dd98:ec7a:4f61])\n\tby smtp.gmail.com with ESMTPSA id\n\tj137sm9920614oih.28.2017.08.26.11.56.07\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tSat, 26 Aug 2017 11:56:08 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=g1qebTt0aOYHGKAG5L4PEizoU+QsFvAv9b12twiS8Z4=;\n\tb=D4VFRgUMnMzdAfD9l38Ch+ciYWAQwHpPywiOtWmazJFHthV3Qvz8nmW4N2JYf79Ilr\n\tCioGTbmbz5nGM2/mQALefAAWGV0PQSPcefoS1EDI27BZBtoVq9WORnBC+QkHGzCYbt8Q\n\ttHJJdwNHrqn7d0pJe8fWKNxQPVq+8JoGcLXQ+CzGcxuBQwlaYsIfVaWGvBrAHrJH/qxK\n\tC68p82DuadGigr4iyX+qAaD0W+khQYNWG6zi6dNdSdzWgHinh+JILJDCutrEGg5V6pEj\n\ttg+aS5t8O1shLHW5xLh8GLdpzP+sPp5Utg0VNhZrz1DaYxChIdWEFwkBov9vha06Ksx4\n\tnDLA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=g1qebTt0aOYHGKAG5L4PEizoU+QsFvAv9b12twiS8Z4=;\n\tb=jShpXN7zvzkdsVt7gOZIqTKIl1vbznJR+0OrzHK+NM3ZbY2FpyBsAbZ5u26X7T8Tzz\n\tJvtHJmdmruXFkRr2R7rlKOid5YajDf8ecUCrdQYIpy/1jpcjTI6LsA1RHRgVTMCLlLF8\n\tJZYrmNJ1kPq80ARAia8j7kXZ4kIUnpm57g6WBwy8duqLdTXW+9qATlx4bK/WjPd4w5sP\n\trIe1kAn1VXuDRrC76P8v5VjMRj68QN35cx/mn0kntZylvsTlVkGkqPSkRcc2xKcCveaR\n\tDUHFhQ12D/SVnqc0on6wP5sLnCOrFZCdiy1LWeBzILAcfhWzo6Dp7/r2qIDnlQvIkH9C\n\tAfrQ==","X-Gm-Message-State":"AHYfb5jGEPTJmxsJaIgObh2eT+7JCHLKU+Fwl24LULqR1RrAic5EKHnj\n\t1hgyTuby5fE6HeX6mqo=","X-Received":"by 10.202.10.92 with SMTP id 89mr2251082oik.156.1503773769505;\n\tSat, 26 Aug 2017 11:56:09 -0700 (PDT)","Subject":"Re: UDP sockets oddities","To":"Eric Dumazet , David Miller ","Cc":"netdev@vger.kernel.org, pabeni@redhat.com, willemb@google.com","References":"<1503712322.11498.12.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<354e6c3a-1771-e8a7-24dd-1b70266563af@gmail.com>\n\t<1503718844.11498.19.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<20170825.211905.920493778125075310.davem@davemloft.net>\n\t<1503751671.11498.25.camel@edumazet-glaptop3.roam.corp.google.com>","From":"Florian Fainelli ","Message-ID":"","Date":"Sat, 26 Aug 2017 11:56:05 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1503751671.11498.25.camel@edumazet-glaptop3.roam.corp.google.com>","Content-Type":"text/plain; charset=windows-1252","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1759579,"web_url":"http://patchwork.ozlabs.org/comment/1759579/","msgid":"<353aa37f-c62b-f5af-8c89-f67af6509497@gmail.com>","list_archive_url":null,"date":"2017-08-29T17:53:27","subject":"Re: UDP sockets oddities","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 08/26/2017 11:56 AM, Florian Fainelli wrote:\n> \n> \n> On 08/26/2017 05:47 AM, Eric Dumazet wrote:\n>> On Fri, 2017-08-25 at 21:19 -0700, David Miller wrote:\n>>\n>>> Agreed, but the ARP resolution queue really needs to scale it's backlog\n>>> to the physical technology it is attached to.\n>> Yes, last time (in 2011) we increased the old limit of 3 packets :/\n>>\n>> We probably should match sysctl_wmem_max so that a single socket\n>> provider would hit its sk_sndbuf limit\n\nEric, do you want to post this as a formal patch? I don't think I\nunderstand these tunables enough to provide a good commit message\nanyways. Thanks!\n\n> \n> Before:\n> /proc/sys/net/ipv4/neigh/eth0/unres_qlen:34\n> /proc/sys/net/ipv4/neigh/eth0/unres_qlen_bytes:65536\n> /proc/sys/net/ipv4/neigh/gphy/unres_qlen:34\n> /proc/sys/net/ipv4/neigh/gphy/unres_qlen_bytes:65536\n> \n> After:\n> /proc/sys/net/ipv4/neigh/eth0/unres_qlen:106\n> /proc/sys/net/ipv4/neigh/eth0/unres_qlen_bytes:229376\n> /proc/sys/net/ipv4/neigh/gphy/unres_qlen:106\n> /proc/sys/net/ipv4/neigh/gphy/unres_qlen_bytes:229376\n> \n> and this does help a lot with the test case reported over an hour, only\n> 2 packets lost:\n> \n> # perf record -a -g -e skb:kfree_skb iperf -c 192.168.1.23 -b 900M -t\n> 3600 -u\n> ------------------------------------------------------------\n> Client connecting to 192.168.1.23, UDP port 5001\n> Sending 1470 byte datagrams, IPG target: 13.07 us (kalman adjust)\n> UDP buffer size: 224 KByte (default)\n> ------------------------------------------------------------\n> [ 4] local 192.168.1.66 port 48209 connected with 192.168.1.23 port 5001\n> write failed: Invalid argument\n> [ ID] Interval Transfer Bandwidth\n> [ 4] 0.0-404.9 sec 4.51 GBytes 95.7 Mbits/sec\n> [ 4] Sent 3294727 datagrams\n> [ 4] Server Report:\n> [ 4] 0.0-405.1 sec 4.51 GBytes 95.6 Mbits/sec 14.979 ms\n> 2/3294728 (6.1e-05%)\n> \n> Thanks Eric!\n> \n>>\n>> Something like :\n>>\n>> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt\n>> index 6b0bc0f715346a097a6df46e2ba2771359abcd23..7777dceb78107c0019fb39d5b69be1959005b78e 100644\n>> --- a/Documentation/networking/ip-sysctl.txt\n>> +++ b/Documentation/networking/ip-sysctl.txt\n>> @@ -109,7 +109,8 @@ neigh/default/unres_qlen_bytes - INTEGER\n>> \tqueued for each\tunresolved address by other network layers.\n>> \t(added in linux 3.3)\n>> \tSetting negative value is meaningless and will return error.\n>> -\tDefault: 65536 Bytes(64KB)\n>> +\tDefault: SK_WMEM_MAX, enough to store 256 packets of medium size\n>> +\t\t (less than 256 bytes per packet)\n>> \n>> neigh/default/unres_qlen - INTEGER\n>> \tThe maximum number of packets which may be queued for each\n>> diff --git a/include/net/sock.h b/include/net/sock.h\n>> index 1c2912d433e81b10f3fdc87bcfcbb091570edc03..03a362568357acc7278a318423dd3873103f90ca 100644\n>> --- a/include/net/sock.h\n>> +++ b/include/net/sock.h\n>> @@ -2368,6 +2368,16 @@ bool sk_net_capable(const struct sock *sk, int cap);\n>> \n>> void sk_get_meminfo(const struct sock *sk, u32 *meminfo);\n>> \n>> +/* Take into consideration the size of the struct sk_buff overhead in the\n>> + * determination of these values, since that is non-constant across\n>> + * platforms. This makes socket queueing behavior and performance\n>> + * not depend upon such differences.\n>> + */\n>> +#define _SK_MEM_PACKETS\t\t256\n>> +#define _SK_MEM_OVERHEAD\tSKB_TRUESIZE(256)\n>> +#define SK_WMEM_MAX\t\t(_SK_MEM_OVERHEAD * _SK_MEM_PACKETS)\n>> +#define SK_RMEM_MAX\t\t(_SK_MEM_OVERHEAD * _SK_MEM_PACKETS)\n>> +\n>> extern __u32 sysctl_wmem_max;\n>> extern __u32 sysctl_rmem_max;\n>> \n>> diff --git a/net/core/sock.c b/net/core/sock.c\n>> index dfdd14cac775e9bfcee0085ee32ffcd0ab28b67b..9b7b6bbb2a23e7652a1f34a305f29d49de00bc8c 100644\n>> --- a/net/core/sock.c\n>> +++ b/net/core/sock.c\n>> @@ -307,16 +307,6 @@ static struct lock_class_key af_wlock_keys[AF_MAX];\n>> static struct lock_class_key af_elock_keys[AF_MAX];\n>> static struct lock_class_key af_kern_callback_keys[AF_MAX];\n>> \n>> -/* Take into consideration the size of the struct sk_buff overhead in the\n>> - * determination of these values, since that is non-constant across\n>> - * platforms. This makes socket queueing behavior and performance\n>> - * not depend upon such differences.\n>> - */\n>> -#define _SK_MEM_PACKETS\t\t256\n>> -#define _SK_MEM_OVERHEAD\tSKB_TRUESIZE(256)\n>> -#define SK_WMEM_MAX\t\t(_SK_MEM_OVERHEAD * _SK_MEM_PACKETS)\n>> -#define SK_RMEM_MAX\t\t(_SK_MEM_OVERHEAD * _SK_MEM_PACKETS)\n>> -\n>> /* Run time adjustable parameters. */\n>> __u32 sysctl_wmem_max __read_mostly = SK_WMEM_MAX;\n>> EXPORT_SYMBOL(sysctl_wmem_max);\n>> diff --git a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c\n>> index 21dedf6fd0f76dec22b2b3685beb89cfefea7ded..22bf0b95d6edc3c27ef3a99d27cb70a1551e3e0e 100644\n>> --- a/net/decnet/dn_neigh.c\n>> +++ b/net/decnet/dn_neigh.c\n>> @@ -94,7 +94,7 @@ struct neigh_table dn_neigh_table = {\n>> \t\t\t[NEIGH_VAR_BASE_REACHABLE_TIME] = 30 * HZ,\n>> \t\t\t[NEIGH_VAR_DELAY_PROBE_TIME] = 5 * HZ,\n>> \t\t\t[NEIGH_VAR_GC_STALETIME] = 60 * HZ,\n>> -\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = 64*1024,\n>> +\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = SK_WMEM_MAX,\n>> \t\t\t[NEIGH_VAR_PROXY_QLEN] = 0,\n>> \t\t\t[NEIGH_VAR_ANYCAST_DELAY] = 0,\n>> \t\t\t[NEIGH_VAR_PROXY_DELAY] = 0,\n>> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c\n>> index 8b52179ddc6e54eabf6d3c2ed0132083228680bb..7c45b8896709815c5dde5972fd57cb5c3bcb2648 100644\n>> --- a/net/ipv4/arp.c\n>> +++ b/net/ipv4/arp.c\n>> @@ -171,7 +171,7 @@ struct neigh_table arp_tbl = {\n>> \t\t\t[NEIGH_VAR_BASE_REACHABLE_TIME] = 30 * HZ,\n>> \t\t\t[NEIGH_VAR_DELAY_PROBE_TIME] = 5 * HZ,\n>> \t\t\t[NEIGH_VAR_GC_STALETIME] = 60 * HZ,\n>> -\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = 64 * 1024,\n>> +\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = SK_WMEM_MAX,\n>> \t\t\t[NEIGH_VAR_PROXY_QLEN] = 64,\n>> \t\t\t[NEIGH_VAR_ANYCAST_DELAY] = 1 * HZ,\n>> \t\t\t[NEIGH_VAR_PROXY_DELAY]\t= (8 * HZ) / 10,\n>> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c\n>> index 5e338eb89509b1df6ebd060f8bd19fcb4b86fe05..266a530414d7be4f1e7be922e465bbab46f7cbac 100644\n>> --- a/net/ipv6/ndisc.c\n>> +++ b/net/ipv6/ndisc.c\n>> @@ -127,7 +127,7 @@ struct neigh_table nd_tbl = {\n>> \t\t\t[NEIGH_VAR_BASE_REACHABLE_TIME] = ND_REACHABLE_TIME,\n>> \t\t\t[NEIGH_VAR_DELAY_PROBE_TIME] = 5 * HZ,\n>> \t\t\t[NEIGH_VAR_GC_STALETIME] = 60 * HZ,\n>> -\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = 64 * 1024,\n>> +\t\t\t[NEIGH_VAR_QUEUE_LEN_BYTES] = SK_WMEM_MAX,\n>> \t\t\t[NEIGH_VAR_PROXY_QLEN] = 64,\n>> \t\t\t[NEIGH_VAR_ANYCAST_DELAY] = 1 * HZ,\n>> \t\t\t[NEIGH_VAR_PROXY_DELAY] = (8 * HZ) / 10,\n>>\n>>\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"eINUuZja\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhbrq24WGz9s8J\n\tfor ;\n\tWed, 30 Aug 2017 03:55:23 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751238AbdH2Rxe (ORCPT );\n\tTue, 29 Aug 2017 13:53:34 -0400","from mail-qk0-f196.google.com ([209.85.220.196]:36796 \"EHLO\n\tmail-qk0-f196.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750822AbdH2Rxd (ORCPT\n\t); Tue, 29 Aug 2017 13:53:33 -0400","by mail-qk0-f196.google.com with SMTP id l65so3465066qkc.3\n\tfor ; Tue, 29 Aug 2017 10:53:32 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\tq26sm2360403qtb.97.2017.08.29.10.53.29\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 29 Aug 2017 10:53:31 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:from:to:cc:references:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=Xd5XMQk5tRUXxrMg1jp3+AYDPngyVE4xo4PkSzlPcJk=;\n\tb=eINUuZjankHATXxX3DwmmZ2QZo6zmsPcHK7JNmw2PL2YLA7VHtXs36xfD0ok4mRECV\n\tq17aLJ2MVQIY0SLuTR4DCCMTHYLSYGDLXKE3IZIWBUZYuABI0MtoqLmNdNr7jDUfOAuD\n\thQbZnHQpeZQ+OCbi3RhMzM6ETp5XVcS0oTIeDG+4miAOriGxY4apLPmpjIJKDsT7efU8\n\t/ycWBPTE54VAHazki7sd8oKijoNaZKtDBpWR8cQh72ToaImZNEHq0LPRTu9L6GZ+H64/\n\twyLlj7HrbE3OxsqZkiP2nB1LTyJmmF3jBmY8bpwgRG3Lte+vV6Tt7Dfur0XrrwU6pilh\n\tI/Mg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:from:to:cc:references:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=Xd5XMQk5tRUXxrMg1jp3+AYDPngyVE4xo4PkSzlPcJk=;\n\tb=V69v1mSxBYQ6GLuWl8R87Cp2Evwl3k9YZ5k3TrCI2Xlq8I1FeU6CNISwDmPU6zuFRY\n\tCp8bH2th6RgDhDMWyhmaqJogzhwhSEi3OaLutTgblS7dLQjlwLNPXADgdSbIg9SfBfj3\n\txTtX5sLE8RmNKHwm8Klh3kuqPli9hc3Q+gYS3iGGtRt3hrwVjAwhgAmDKeksSJEyE3Wi\n\tHtRPMBuiFwobyZ26wmD3FydVLZ6v0dnG3BWYMLnl6f+GPHQCkzTmrbKhBdWCfyaoNq0D\n\tmLMgzrXBcYdOiryTZfRyQkusfXJBp+E3RjQATtd35NS8x6HwhkkxjS/A7TKE3eqIpAcU\n\tDNvQ==","X-Gm-Message-State":"AHYfb5hxMwFojQbSizOLs2nSMqjXCUnwaLwZTalYznXNfE9dWHRd7T8b\n\taRpV4P9TwKcsKw==","X-Received":"by 10.233.237.12 with SMTP id c12mr7401798qkg.268.1504029212387; \n\tTue, 29 Aug 2017 10:53:32 -0700 (PDT)","Subject":"Re: UDP sockets oddities","From":"Florian Fainelli ","To":"Eric Dumazet , David Miller ","Cc":"netdev@vger.kernel.org, pabeni@redhat.com, willemb@google.com","References":"<1503712322.11498.12.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<354e6c3a-1771-e8a7-24dd-1b70266563af@gmail.com>\n\t<1503718844.11498.19.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<20170825.211905.920493778125075310.davem@davemloft.net>\n\t<1503751671.11498.25.camel@edumazet-glaptop3.roam.corp.google.com>\n\t","Message-ID":"<353aa37f-c62b-f5af-8c89-f67af6509497@gmail.com>","Date":"Tue, 29 Aug 2017 10:53:27 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1759586,"web_url":"http://patchwork.ozlabs.org/comment/1759586/","msgid":"<1504029689.11498.79.camel@edumazet-glaptop3.roam.corp.google.com>","list_archive_url":null,"date":"2017-08-29T18:01:29","subject":"Re: UDP sockets oddities","submitter":{"id":2404,"url":"http://patchwork.ozlabs.org/api/people/2404/","name":"Eric Dumazet","email":"eric.dumazet@gmail.com"},"content":"On Tue, 2017-08-29 at 10:53 -0700, Florian Fainelli wrote:\n> On 08/26/2017 11:56 AM, Florian Fainelli wrote:\n> > \n> > \n> > On 08/26/2017 05:47 AM, Eric Dumazet wrote:\n> >> On Fri, 2017-08-25 at 21:19 -0700, David Miller wrote:\n> >>\n> >>> Agreed, but the ARP resolution queue really needs to scale it's backlog\n> >>> to the physical technology it is attached to.\n> >> Yes, last time (in 2011) we increased the old limit of 3 packets :/\n> >>\n> >> We probably should match sysctl_wmem_max so that a single socket\n> >> provider would hit its sk_sndbuf limit\n> \n> Eric, do you want to post this as a formal patch? I don't think I\n> understand these tunables enough to provide a good commit message\n> anyways. Thanks!\n\nI will post it today.\n\nI was out of the office yesterday, rafting on the south fork of American\nRiver ;)\n\n\nThis will target net-next.\n\nThanks.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"i1tZQ2uu\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhbzz2T7Xz9s81\n\tfor ;\n\tWed, 30 Aug 2017 04:01:35 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751223AbdH2SBd (ORCPT );\n\tTue, 29 Aug 2017 14:01:33 -0400","from mail-pf0-f174.google.com ([209.85.192.174]:35951 \"EHLO\n\tmail-pf0-f174.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750822AbdH2SBc (ORCPT\n\t); Tue, 29 Aug 2017 14:01:32 -0400","by mail-pf0-f174.google.com with SMTP id z87so12280246pfi.3\n\tfor ; Tue, 29 Aug 2017 11:01:32 -0700 (PDT)","from ?IPv6:2620:15c:2c1:100:5c25:69da:43fc:a7c6?\n\t([2620:15c:2c1:100:5c25:69da:43fc:a7c6])\n\tby smtp.googlemail.com with ESMTPSA id\n\tb29sm7167163pfh.22.2017.08.29.11.01.30\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 29 Aug 2017 11:01:30 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=message-id:subject:from:to:cc:date:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=kZqIqHRfQajTZWm4EdYqQR3+kJjYfTkXxPQriB6QoT0=;\n\tb=i1tZQ2uuee/Pga1cFopaq3Zh8HWqflN712LHCYswrTstf2fFwgertAkZJZr3Y+LCAt\n\tfFrM+pH3/1nL9nRKT6NB93rOatSqepq9MD/YtE0NDreuTqp4lKXl0i8Q0m4fOt1zwwBc\n\t9Yb0d/JQgLiE3S1UOa+u0a13cqWUIIYIRtIZBoMfqoZUJy78/DzW+QNHQvTapHSwqWJs\n\tnkeEjnDfQUYbSRPAr/d1t3U5QJUB6nG8YIJtVXCKrxWrrIC8cue5Fl9IqDm3FMq/CQXh\n\tG3DlhT/r2oDdM8mV3Lrl81SE4kI7xnYbCuNAPVNpxCKBLmht2sVKot3xzMl5MvLw0Yhx\n\tQAdA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=kZqIqHRfQajTZWm4EdYqQR3+kJjYfTkXxPQriB6QoT0=;\n\tb=kIwU4YTaDq22lpa/zt2pH4OTLcLhYX6U5rkzbqIRPV8Ljrx2GH7eYFDKm8KqOCO9zz\n\tdVKsgmgSJ4Fru0hgtS8mtfs+VxCsVlb65XH19TOSZ+56YcuSTEOPESuhLuMdYhXWpZ7F\n\tEFUW2wfjpjH7NHpifto9LcNiOOmXotbi/WH9/A0cEqPiiFrcEeCprppFnTQ5462gUSc+\n\tM/hRU4qf2Ft9RuICgJc49ZO+psMlBug4Dphsb/+lBFejLv3P04s9tZHzWkpB0Eo5hvUA\n\tPr01bIwQcVKZJq/QjNOCEKYBGIoiiXIyjwmsNrUWOwtYf5wi9aIGkHVw1j2CrCG69Uc2\n\tkWpA==","X-Gm-Message-State":"AHYfb5hFf9Y/UQl4rvDrYGUX8Bmb+2dHNYIAGwe6WREXld0RuUwvolsC\n\tsofyOy+PAvkBmcg1","X-Received":"by 10.84.229.71 with SMTP id d7mr1407982pln.237.1504029691368;\n\tTue, 29 Aug 2017 11:01:31 -0700 (PDT)","Message-ID":"<1504029689.11498.79.camel@edumazet-glaptop3.roam.corp.google.com>","Subject":"Re: UDP sockets oddities","From":"Eric Dumazet ","To":"Florian Fainelli ","Cc":"David Miller , netdev@vger.kernel.org,\n\tpabeni@redhat.com, willemb@google.com","Date":"Tue, 29 Aug 2017 11:01:29 -0700","In-Reply-To":"<353aa37f-c62b-f5af-8c89-f67af6509497@gmail.com>","References":"<1503712322.11498.12.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<354e6c3a-1771-e8a7-24dd-1b70266563af@gmail.com>\n\t<1503718844.11498.19.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<20170825.211905.920493778125075310.davem@davemloft.net>\n\t<1503751671.11498.25.camel@edumazet-glaptop3.roam.corp.google.com>\n\t\n\t<353aa37f-c62b-f5af-8c89-f67af6509497@gmail.com>","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.10.4-0ubuntu2 ","Mime-Version":"1.0","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]