On Fri, Jul 26, 2024 at 03:32:48PM +0200, Florian Westphal wrote: > Ido Schimmel <idosch@xxxxxxxxxx> wrote: > > @@ -110,7 +108,7 @@ void nft_fib4_eval(const struct nft_expr *expr, struct nft_regs *regs, > > if (priv->flags & NFTA_FIB_F_MARK) > > fl4.flowi4_mark = pkt->skb->mark; > > > > - fl4.flowi4_tos = iph->tos & DSCP_BITS; > > + fl4.flowi4_tos = iph->tos & IPTOS_RT_MASK; > > If this is supposed to get centralised, wouldn't it > make more sense to not mask it, or will that happen later? I think Ido prefers to have this behaviour introduced in a dedicated patch, rather than as a side effect of the centralisation done in patch 3/3. Once patch 3/3 is applied, the next step would be to remove all those redundant masks (including this new nft_fib4_eval() one), so that fib4_rule_match(), fib_table_lookup() and fib_select_default() could see the full DSCP. This will allow the final step of allowing IPv4 routes and fib-rules to be configured for matching either the DSCP bits or only the old TOS ones. > I thought plan was to ditch RT_MASK... That was my preference too. But Ido's affraid of potential users who may depend on fib-rules with tos=0x1c matching packets with dsfield=0xfc. Centralising the mask would allow us to configure this behaviour upon route or fib-rule creation. Here's the original thread that lead to this RFC, if anyone wants more details on the current plan: https://lore.kernel.org/netdev/ZnwCWejSuOTqriJc@xxxxxxxxxxxxxxxx/
