[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210930090652.4f91be57@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Thu, 30 Sep 2021 09:06:52 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Daniel Borkmann <daniel@...earbox.net>,
netfilter-devel@...r.kernel.org, davem@...emloft.net,
netdev@...r.kernel.org, lukas@...ner.de, kadlec@...filter.org,
fw@...len.de, ast@...nel.org, edumazet@...gle.com, tgraf@...g.ch,
nevola@...il.com, john.fastabend@...il.com, willemb@...gle.com
Subject: Re: [PATCH nf-next v5 0/6] Netfilter egress hook
On Thu, 30 Sep 2021 17:13:37 +0200 Pablo Neira Ayuso wrote:
> On Thu, Sep 30, 2021 at 07:28:35AM -0700, Jakub Kicinski wrote:
> > The lifetime of this information is constrained, can't it be a percpu
> > flag, like xmit_more?
>
> It's just one single bit in this case after all.
??
> > > Probably the sysctl for this new egress hook is the way to go as you
> > > suggest.
> >
> > Knobs is making users pay, let's do our best to avoid that.
>
> Could you elaborate?
My reading of Daniel's objections was that the layering is incorrect
because tc is not exclusively "under" nf. That problem is not solved
by adding a knob. The only thing the knob achieves is let someone
deploying tc/bpf based solution protect themselves from accidental
nf deployment.
That's just background / level set. IDK what requires explanation
in my statement itself. I thought "admin knobs are bad" is as
universally agreed on as, say, "testing is good".
Powered by blists - more mailing lists