From d79c1587084520e3513eaca5eb7b3dbd6500d14d Mon Sep 17 00:00:00 2001 From: Christoph Anton Mitterer Date: Sat, 11 Oct 2025 02:23:57 +0200 Subject: [PATCH] doc: clarify evaluation of chains MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit In particular: - Mention that grouping of chains in tables is irrelevant to the evaluation order. - Clarify that priorities only define the ordering of chains per hook. - Improved potentially ambiguous wording “lower priority values have precedence over higher ones”, which could be mistaken as that rules from lower priority chains might “win” over such from higher ones (which is however only the case if they drop/reject packets). The new wording merely describes which chains are evaluated first, implicitly referring the question which verdict “wins” to the section where verdicts are described, and also should work when lower priority chains mangle packets (in which case they might actually be considered as having “precedence”). Signed-off-by: Christoph Anton Mitterer Signed-off-by: Florian Westphal --- doc/nft.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/nft.txt b/doc/nft.txt index 42cdd38a..78dbef66 100644 --- a/doc/nft.txt +++ b/doc/nft.txt @@ -465,8 +465,10 @@ status. The *priority* parameter accepts a signed integer value or a standard priority name which specifies the order in which chains with the same *hook* value are -traversed. The ordering is ascending, i.e. lower priority values have precedence -over higher ones. +traversed (regardless of the table to which they belong). The ordering is +ascending: for each hook, chains with lower priority values are evaluated +before those with higher ones. The ordering of chains with identical priority +is undefined. With *nat* type chains, there's a lower excluding limit of -200 for *priority* values, because conntrack hooks at this priority and NAT requires it. -- 2.47.3