Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: dust.li@linux.alibaba.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, 08 Sep 2020 10:46:13 +0200	[thread overview]
Message-ID: <f13eaa33c4f73bce9bdcf08b072aeaf23b0551d5.camel@redhat.com> (raw)
In-Reply-To: <20200908031506.GC56680@linux.alibaba.com>

Hi,

On Tue, 2020-09-08 at 11:15 +0800, dust.li wrote:
> 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].

Sure, but with enough sockets you can also exceeeds any limits ;).

> 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;

At this point, the above condition is always true, due to an earlier
check. Additionally, accepting any value below udp_mem[2] would make
the previous checks to allow a minimum per socket memory useless.

You can obtain the same result setting udp_mem[0] = udp_mem[2], without
any kernel change. 

But with this change applied you can't guarantee anymore a minimum per
socket amount of memory.

I think you are possibly mislead by your own comment: the point is that
we should never allow allocation above the hard limit, but the protocol
is allowed to drop as soon as the memory allocated raises above the
lower limit.

Note that the current behavior is correctly documented
in Documentation/networking/ip-sysctl.rst.

Your problem must be solved in another way e.g. raising udp_mem[0] -
and keeping udp_mem[2] above that value.

Cheers,

Paolo


  reply	other threads:[~2020-09-08  8:46 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
2020-09-08  8:46     ` Paolo Abeni [this message]
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=f13eaa33c4f73bce9bdcf08b072aeaf23b0551d5.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dust.li@linux.alibaba.com \
    --cc=edumazet@google.com \
    --cc=netdev@vger.kernel.org \
    /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 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).