From: Guillaume Nault <gnault@redhat•com>
To: Florian Westphal <fw@strlen•de>
Cc: Ido Schimmel <idosch@nvidia•com>,
netdev@vger•kernel.org, netfilter-devel@vger•kernel.org,
davem@davemloft•net, kuba@kernel•org, pabeni@redhat•com,
edumazet@google•com, dsahern@kernel•org, pablo@netfilter•org,
kadlec@netfilter•org
Subject: Re: [RFC PATCH net-next 2/3] netfilter: nft_fib: Mask upper DSCP bits before FIB lookup
Date: Fri, 26 Jul 2024 17:40:47 +0200 [thread overview]
Message-ID: <ZqPDf00MuoI677T/@debian> (raw)
In-Reply-To: <20240726133248.GA5302@breakpoint.cc>
On Fri, Jul 26, 2024 at 03:32:48PM +0200, Florian Westphal wrote:
> Ido Schimmel <idosch@nvidia•com> 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@shredder.mtl.com/
next prev parent reply other threads:[~2024-07-26 15:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-25 13:17 [RFC PATCH net-next 0/3] Preparations for FIB rule DSCP selector Ido Schimmel
2024-07-25 13:17 ` [RFC PATCH net-next 1/3] ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family Ido Schimmel
2024-07-26 13:12 ` Guillaume Nault
2024-07-25 13:17 ` [RFC PATCH net-next 2/3] netfilter: nft_fib: Mask upper DSCP bits before FIB lookup Ido Schimmel
2024-07-26 13:15 ` Guillaume Nault
2024-07-26 13:32 ` Florian Westphal
2024-07-26 15:40 ` Guillaume Nault [this message]
2024-07-28 2:30 ` Florian Westphal
2024-07-28 10:51 ` Ido Schimmel
2024-07-25 13:17 ` [RFC PATCH net-next 3/3] ipv4: Centralize TOS matching Ido Schimmel
2024-07-26 13:17 ` Guillaume Nault
2024-07-28 11:34 ` Ido Schimmel
2024-07-29 16:05 ` Guillaume Nault
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZqPDf00MuoI677T/@debian \
--to=gnault@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dsahern@kernel$(echo .)org \
--cc=edumazet@google$(echo .)com \
--cc=fw@strlen$(echo .)de \
--cc=idosch@nvidia$(echo .)com \
--cc=kadlec@netfilter$(echo .)org \
--cc=kuba@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=netfilter-devel@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=pablo@netfilter$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox