nf_tables can handle payload exprs for sizes <= sizeof(u32) via a direct operation from the eval loop, rather than a a call to the payload expression. Two loads for four byte quantities are thus faster than a single load for an 8 byte load. ip saddr 1.2.3.4 ip daddr 2.3.4.5 is faster with this applied, even though it involves two payload expressions and two compare operations, just because all of them can be handled from the main loop rather than calls to the payload expression. Keep merging for linklayer and when at least one of the expressions is already exceeding the 4 byte limit, then it will be cheaper to do the merging. Signed-off-by: Florian Westphal <fw@xxxxxxxxx> --- src/payload.c | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/src/payload.c b/src/payload.c index 6517686cbfba..36991401e1d3 100644 --- a/src/payload.c +++ b/src/payload.c @@ -719,7 +719,33 @@ bool payload_can_merge(const struct expr *e1, const struct expr *e2) if (total < e1->len || total > (NFT_REG_SIZE * BITS_PER_BYTE)) return false; - return true; + /* could return true after this, the expressions are mergeable. + * + * However, there are some caveats. + * + * Loading anything <= sizeof(u32) with base >= network header + * is fast, because its handled directly from eval loop in the + * kernel. + * + * We thus restrict merging a bit more. + */ + + /* can still be handled by fastpath after merge */ + if (total <= NFT_REG32_SIZE * BITS_PER_BYTE) + return true; + + /* Linklayer base is not handled in fastpath, merge */ + if (e1->payload.base == PROTO_BASE_LL_HDR) + return true; + + /* Also merge if at least one expression is already + * above REG32 size, in this case merging is faster. + */ + if (e1->len > (NFT_REG32_SIZE * BITS_PER_BYTE) || + e2->len > (NFT_REG32_SIZE * BITS_PER_BYTE)) + return true; + + return false; } /** -- 2.19.2
