Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dust Li <dust.li@linux.alibaba.com>
To: "David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>, Hideo Aoki <haoki@redhat.com>
Cc: netdev@vger.kernel.org
Subject: [PATCH] net/sock: don't drop udp packets if udp_mem[2] not reached
Date: Mon, 7 Sep 2020 22:44:35 +0800 [thread overview]
Message-ID: <20200907144435.43165-1-dust.li@linux.alibaba.com> (raw)
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
3. The udp server receive slowly, causing the udp_prot->memory_allocated
exceed udp_mem[0], but still under udp_mem[2]
I wrote a test script to reproduce this:
https://github.com/dust-li/kernel-test/blob/master/exceed_udp_mem_min_drop/exceed_udp_mem_min_drop.sh
Obviously, we should not drop packets when udp_prot.memory_allocated
just exceed udp_mem[0] but still under hard limit.
For protocols with memory_pressure callbacks (like TCP), this is
not a problem, because there is an extra check:
```
if (sk_has_memory_pressure(sk)) {
u64 alloc;
if (!sk_under_memory_pressure(sk))
return 1;
alloc = sk_sockets_allocated_read_positive(sk);
if (sk_prot_mem_limits(sk, 2) > alloc *
sk_mem_pages(sk->sk_wmem_queued +
atomic_read(&sk->sk_rmem_alloc) +
sk->sk_forward_alloc))
return 1;
}
```
But UDP didn't check this, so I add an extra check here
to make sure UDP packets are not dropped until the hard limit
is reached.
Signed-off-by: Dust Li <dust.li@linux.alibaba.com>
---
net/core/sock.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/core/sock.c b/net/core/sock.c
index 6c5c6b18eff4..fed8211d8dbe 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2648,6 +2648,12 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)
atomic_read(&sk->sk_rmem_alloc) +
sk->sk_forward_alloc))
return 1;
+ } else {
+ /* for prots without memory_pressure callbacks, we should not
+ * drop until hard limit reached
+ */
+ if (allocated <= sk_prot_mem_limits(sk, 2))
+ return 1;
}
suppress_allocation:
--
2.19.1.3.ge56e4f7
next reply other threads:[~2020-09-07 15:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 14:44 Dust Li [this message]
2020-09-07 17:18 ` Paolo Abeni
2020-09-08 3:15 ` dust.li
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=20200907144435.43165-1-dust.li@linux.alibaba.com \
--to=dust.li@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=haoki@redhat.com \
--cc=netdev@vger.kernel.org \
--subject='Re: [PATCH] net/sock: don'\''t drop udp packets if udp_mem[2] not reached' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).