All of lore.kernel.org
 help / color / mirror / Atom feed
From: "dust.li" <dust.li@linux.alibaba.com>
To: Paolo Abeni <pabeni@redhat.com>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] net/sock: don't drop udp packets if udp_mem[2] not reached
Date: Tue, 8 Sep 2020 11:15:06 +0800	[thread overview]
Message-ID: <20200908031506.GC56680@linux.alibaba.com> (raw)
In-Reply-To: <428dae2552915c42b9144d7489fd912493433c1e.camel@redhat.com>

On Mon, Sep 07, 2020 at 07:18:48PM +0200, Paolo Abeni wrote:
>Hi,
>
>On Mon, 2020-09-07 at 22:44 +0800, Dust Li wrote:
>> We encoutered udp packets drop under a pretty low pressure
>> with net.ipv4.udp_mem[0] set to a small value (4096).
>> 
>> After some tracing and debugging, we found that for udp
>> protocol, __sk_mem_raise_allocated() will possiblly drop
>> packets if:
>>   udp_mem[0] < udp_prot.memory_allocated < udp_mem[2]
>> 
>> That's because __sk_mem_raise_allocated() didn't handle
>> the above condition for protocols like udp who doesn't
>> have sk_has_memory_pressure()
>> 
>> We can reproduce this with the following condition
>> 1. udp_mem[0] is relateive small,
>> 2. net.core.rmem_default/max > udp_mem[0] * 4K
>
>This looks like something that could/should be addressed at
>configuration level ?!?
Thanks a lot for the review !

Sorry, maybe I haven't make it clear enough

The real problem is the scability with the sockets number.
Since the udp_mem is for all UDP sockets, with the number of udp
sockets grows, soon or later, udp_prot.memory_allocated will
exceed udp_mem[0], and __sk_mem_raise_allocated() will cause
the packets drop here. But the total udp memory allocated
may still far under udp_mem[1] or udp_mem[2]

>
>udp_mem[0] should accomodate confortably at least a socket.

Yeah, I agree udp_mem[0] should be large enough for at least a
socket.

Here I use 4096 just for simple and reproduce what we met before.

I changed my test program a bit:
 - with 16 server sockets
 - with 1 client sending 3000 messages(size: 4096bytes) to each
   of those 8 server sockets
 - set net.core.rmem_default/max to (2*4096*4096)
 - and keep udp_mem unset, which by default on my 4GB VM is
   'net.ipv4.udp_mem = 91944        122592  183888'

https://github.com/dust-li/kernel-test/blob/master/exceed_udp_mem_min_drop/multi_sockets_test.sh


Actually, with more udp sockets, I can always make it large
enough to exceed udp_mem[0], and drop packets before udp_mem[1]
and udp_mem[2].

>
>Cheers,
>
>Paolo

  reply	other threads:[~2020-09-08  3:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07 14:44 [PATCH] net/sock: don't drop udp packets if udp_mem[2] not reached Dust Li
2020-09-07 17:18 ` Paolo Abeni
2020-09-08  3:15   ` dust.li [this message]
2020-09-08  8:46     ` Paolo Abeni
2020-09-09  3:24       ` dust.li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200908031506.GC56680@linux.alibaba.com \
    --to=dust.li@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.