On 2019-12-09, at 23:47:10 +0100, Florian Westphal wrote:
> Jeremy Sowden wrote:
> > "ct dscpmark" is a method of storing the DSCP of an ip packet into
> > the conntrack mark.  In combination with a suitable tc filter action
> > (act_ctinfo) DSCP values are able to be stored in the mark on egress
> > and restored on ingress across links that otherwise alter or bleach
> > DSCP.
> >
> > This is useful for qdiscs such as CAKE which are able to shape
> > according to policies based on DSCP.
> >
> > Ingress classification is traditionally a challenging task since
> > iptables rules haven't yet run and tc filter/eBPF programs are
> > pre-NAT lookups, hence are unable to see internal IPv4 addresses as
> > used on the typical home masquerading gateway.
> >
> > The "ct dscpmark" conntrack statement solves the problem of storing
> > the DSCP to the conntrack mark in a way suitable for the new
> > act_ctinfo tc action to restore.
>
> Yes, but if someone else wants to store ip saddr or udp port or
> ifindex or whatever we need to extend this again.
>
> nft should be able to support:
>
> nft add rule inet filter forward ct mark set ip dscp
>
> (nft will reject this because types are different).
>
> Same for
>
> nft add rule inet filter forward ct mark set ip dscp << 16
>
> (nft will claim the shift is unsupported for a 8 bit type).
>
> We need a cast operator for this.  Something like
>
> nft add rule inet filter forward ct mark set typeof(ct mark) ip dscp
>
> or anything else that tells the parser that we really want the
> diffserv value to be assigned to a mark type.
>
> As far as I can see, no kernel changes would be reqired for this.
>
> A cheap starting point would be to try to get rid of the sanity test
> and make nft just accept the right-hand-side of 'ct mark set', then
> see how to best add an 'do this anyway' override in the grammar.
>
> I have older patches that adds a 'typeof' keyword for set definitions,
> maybe it could be used for this casting too.

These?

  https://lore.kernel.org/netfilter-devel/20190816144241.11469-1-fw@strlen.de/

J.