All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Sven Auhagen <sven.auhagen@voleatech.de>
Cc: netfilter-devel@vger.kernel.org, fw@strlen.de, pablo@netfilter.org
Subject: Re: Could not process rule: Cannot allocate memory
Date: Wed, 8 May 2024 16:08:20 +0200	[thread overview]
Message-ID: <20240508140820.GB28190@breakpoint.cc> (raw)
In-Reply-To: <qfqcb3jgkeovcelauadxyxyg65ps32nndcdutwcjg55wpzywkr@vzgi3sh2izrw>

Sven Auhagen <sven.auhagen@voleatech.de> wrote:
> When the sets are larger I now always get an error:
> ./main.nft:13:1-26: Error: Could not process rule: Cannot allocate memory
> destroy table inet filter
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> along with the kernel message
> percpu: allocation failed, size=16 align=8 atomic=1, atomic alloc failed, no space left

This specific pcpu allocation failure aside, I think we need to reduce
memory waste with flush op.

Flushing a set with 1m elements will need >100Mbyte worth of memory for
the delsetelem transactional log.

The ratio of preamble to set_elem isn't great, we need 88 bytes for the
nft_trans struct and 24 bytes to store one set elem, i.e. 112 bytes per
to-be-deleted element.

I'd say we should look into adding a del_setelem_many struct that stores
e.g. up to 20 elem_priv pointers.  With such a ratio we could probably
get memory waste down to ~20 Mbytes for 1m element sets.

  parent reply	other threads:[~2024-05-08 14:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-08 10:21 Could not process rule: Cannot allocate memory Sven Auhagen
2024-05-08 12:15 ` Florian Westphal
2024-05-08 14:06   ` Sven Auhagen
2024-05-08 14:09     ` Florian Westphal
2024-05-08 12:52 ` [PATCH nf-next] netfilter: nf_tables: allow clone callbacks to sleep Florian Westphal
2024-05-08 14:08 ` Florian Westphal [this message]
2024-05-08 14:25   ` Could not process rule: Cannot allocate memory Jan Engelhardt
2024-05-08 14:36   ` Sven Auhagen
2024-05-10  9:06   ` Florian Westphal
2024-05-10 10:45     ` Sven Auhagen
2024-05-10 10:51       ` Pablo Neira Ayuso
2024-05-10 11:53         ` Sven Auhagen
2024-05-10 11:05       ` Florian Westphal

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=20240508140820.GB28190@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=sven.auhagen@voleatech.de \
    /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.