On Tue, 30 Jul 2019 12:54:17 +0200, Pablo Neira Ayuso wrote:
> This patch maps basechain netfilter priorities from -8192 to 8191 to
> hardware priority 0xC000 + 1. tcf_auto_prio() uses 0xC000 if the user
> specifies no priority, then it subtract 1 for each new tcf_proto object.
> This patch uses the hardware priority range from 0xC000 to 0xFFFF for
> netfilter.
>
> Signed-off-by: Pablo Neira Ayuso <[email protected]>
> ---
> This follows a rather conservative approach, I could just expose the
> 2^16 hardware priority range, but we may need to split this priority
> range among the ethtool_rx, tc and netfilter subsystems to start with
> and it should be possible to extend the priority range later on.
>
> By netfilter priority, I'm refering to the basechain priority:
>
> add chain x y { type filter hook ingress device eth0 priority 0; }
> ^^^^^^^^^^^
>
> This is no transparently mapped to hardware, this patch shifts it to
> make it fit into the 0xC000 + 1 .. 0xFFFF hardware priority range.
Mmm.. so the ordering of tables is intended to be decided by priority
and not block type (nft, tc, ethtool)? I was always expecting we
would just follow the software order when it comes to inter-subsystem
decisions. So ethtool first, then XDP, then TC, then nft, then
bridging etc. TC vs NFT based on:
static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc,
struct packet_type **ppt_prev)
{
...
if (static_branch_unlikely(&ingress_needed_key)) {
skb = sch_handle_ingress(skb, &pt_prev, &ret, orig_dev);
if (!skb)
goto out;
if (nf_ingress(skb, &pt_prev, &ret, orig_dev) < 0)
goto out;
}
Are they solid use cases for choosing the ordering arbitrarily?
