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 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 simply describes in which are evalauted first, which implicitly refers the question which verdict “wins” to the section where verdicts are described, but also should work when lower priority chains mangle packages (in which case they might actually be considered as having “precedence”). Link: https://lore.kernel.org/netfilter-devel/3c7ddca7029fa04baa2402d895f3a594a6480a3a.camel@scientia.org/T/#t Signed-off-by: Christoph Anton Mitterer --- doc/nft.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/nft.txt b/doc/nft.txt index 87129819..c7d8500d 100644 --- a/doc/nft.txt +++ b/doc/nft.txt @@ -453,8 +453,10 @@ interface specified in the *device* parameter. 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, i.e. per hook, chains with lower priority values are evaluated before +those with higher ones and the ordering of such with the same priority value +being 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.51.0