all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Stefan Hanreich <s.hanreich@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [PATCH pve-firewall 3/3] fix #1965: firewall: cache cluster config
Date: Wed, 4 Nov 2026 17:36:44 +0100	[thread overview]
Message-ID: <c73737b2-1c64-465a-a4b3-92a6e302ebcb@proxmox.com> (raw)
In-Reply-To: <20261104141931.399659-4-a.bied-charreton@proxmox.com>

On 11/4/26 3:20 PM, Arthur Bied-Charreton wrote:
> Large firewall configs can take a noticeable amount of time to parse,
> as noted by the user on the linked issue.
> 
> Register the config with cfs_register_file in order to avoid re-parsing
> it unless cluster.fw changed.
> 
> Rule verification still depends on the SDN config, which can change
> independently. A rule referencing an SDN ipset that did not exist when
> it was parsed and cached is still stored with errors, even if that rule
> becomes valid later (e.g. if the rule references 'foo-dhcp' and the
> VNet 'foo' is created later).
> 
> For this reason, the cached config keeps the SDN config it was verified
> against last time it was fully parsed. If the ipset names yielded by the
> current SDN config differ from what is stored, all cluster and group
> rules are re-verified against the new ones. The ccache cannot be
> invalidated from pve-firewall, so after an SDN change this happens on
> every load until cluster.fw is parsed again due to a new version or a
> daemon restart.
> 
> Errors found on re-verification are logged to preserve the original
> behavior.
> 
> Benchmark with two 25k-entry ipsets and 1050 rules (50 loads):
> 
>     without caching:
>         first load 0.2447s, then avg 0.2509s (min 0.2301 max 0.2835)
> 
>     cached, not re-verified (steady state):
>         first load 0.2694s, then avg 0.0157s (min 0.0131 max 0.0204)
> 
>     cached, re-verified (worst case, transient until next parse):
>         avg 0.0721s (min 0.0657 max 0.1012)
That is with eea1b88b9 applied already? In that case the gain seems
marginal? Are there other possible configurations that would get
a bigger speed up. Because the core problem seems to be addressed
with eea1b88b9 alone and then we don't have the added logic of
re-verifying / caching?




  parent reply	other threads:[~2026-11-04 16:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 14:19 [PATCH firewall 0/3] fix #1965: cache the cluster firewall config Arthur Bied-Charreton
2026-11-04 14:19 ` [PATCH pve-firewall 1/3] firewall: run make tidy Arthur Bied-Charreton
2026-11-04 14:19 ` [PATCH pve-firewall 2/3] firewall: parser: factor out error logging Arthur Bied-Charreton
2026-11-04 14:19 ` [PATCH pve-firewall 3/3] fix #1965: firewall: cache cluster config Arthur Bied-Charreton
2026-11-04 16:15   ` Stefan Hanreich
2026-11-05  8:19     ` Arthur Bied-Charreton
2026-11-04 16:36   ` Stefan Hanreich [this message]
2026-11-05  8:15     ` Arthur Bied-Charreton

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=c73737b2-1c64-465a-a4b3-92a6e302ebcb@proxmox.com \
    --to=s.hanreich@proxmox.com \
    --cc=pve-devel@lists.proxmox.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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal