netdev - Re: Kernel UDP behavior with missing destinations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1f6a6c3f-d723-4739-da77-58a55cfa2170@gmail.com>
Date:   Thu, 16 May 2019 10:03:16 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Adam Urban <adam.urban@...leguru.org>,
        Eric Dumazet <eric.dumazet@...il.com>
Cc:     Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: Kernel UDP behavior with missing destinations



On 5/16/19 9:32 AM, Adam Urban wrote:
> Eric, thanks. Increasing wmem_default from 229376 to 2293760 indeed
> makes the issue go away on my test bench. What's a good way to
> determine the optimal value here? I assume this is in bytes and needs
> to be large enough so that the SO_SNDBUF doesn't fill up before the
> kernel drops the packets. How often does that happen?

You have to count the max number of arp queues your UDP socket could hit.

Say this number is X

Then wmem_default should be set  to X * unres_qlen_bytes + Y

With Y =  229376  (the default  wmem_default)

Then, you might need to increase the qdisc limits.

If no arp queue is active, all UDP packets could be in the qdisc and might hit sooner
the qdisc limit, thus dropping packets on the qdisc.

(This is assuming your UDP application can blast packets at a rate above the link rate)

> 
> On Thu, May 16, 2019 at 12:14 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
>>
>>
>>
>> On 5/16/19 9:05 AM, Eric Dumazet wrote:
>>
>>> We probably should add a ttl on arp queues.
>>>
>>> neigh_probe() could do that quite easily.
>>>
>>
>> Adam, all you need to do is to increase UDP socket sndbuf.
>>
>> Either by increasing /proc/sys/net/core/wmem_default
>>
>> or using setsockopt( ... SO_SNDBUF ... )
>>