On 9/30/21 8:52 AM, Lukas Wunner wrote:
On Thu, Sep 30, 2021 at 08:08:53AM +0200, Daniel Borkmann wrote:Hm, so in the case of SRv6 users were running into a similar issue and commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane") [0] added a new hook along with a sysctl which defaults the new hook to off. The rationale for it was given as "the hooks are enabled via nf_hooks_lwtunnel sysctl to make sure existing netfilter rulesets do not break." [0,1] If the suggestion to flag the skb [2] one way or another from the tc forwarding path (e.g. skb bit or per-cpu marker) is not technically feasible, then why not do a sysctl toggle like in the SRv6 case?The skb flag *is* technically feasible. I amended the patches with the flag and was going to post them this week, but Pablo beat me to the punch and posted his alternative version, which lacks the flag but modularizes netfilter ingress/egress processing instead. Honestly I think a hodge-podge of config options and sysctl toggles is awful and I would prefer the skb flag you suggested. I kind of like your idea of considering tc and netfilter as layers. FWIW the finished patches *with* the flag are on this branch: https://github.com/l1k/linux/commits/nft_egress_v5 Below is the "git range-diff" between Pablo's patches and mine (just the hunks which pertain to the skb flag, plus excerpts from the commit message). Would you find the patch set acceptable with this skb flag?
Yes, that looks good to me, thanks Lukas!
