[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191123142305.g2kkaudhhyui22fq@wunner.de>
Date: Sat, 23 Nov 2019 15:23:05 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
Jozsef Kadlecsik <kadlec@...filter.org>,
Florian Westphal <fw@...len.de>,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
netdev@...r.kernel.org, Martin Mares <mj@....cz>
Subject: Re: [PATCH nf-next,RFC 5/5] netfilter: Introduce egress hook
On Thu, Oct 31, 2019 at 11:39:58PM +0100, Daniel Borkmann wrote:
> On 10/31/19 2:41 PM, Lukas Wunner wrote:
> > Commit e687ad60af09 ("netfilter: add netfilter ingress hook after
> > handle_ing() under unique static key") introduced the ability to
> > classify packets on ingress.
> >
> > Allow the same on egress.
> >
> > The need for this arose because I had to filter egress packets which do
> > not match a specific ethertype. The most common solution appears to be
> > to enslave the interface to a bridge and use ebtables, but that's
> > cumbersome to configure and comes with a (small) performance penalty.
> > An alternative approach is tc, but that doesn't afford equivalent
> > matching options as netfilter.
>
> Hmm, have you tried tc BPF on the egress hook (via sch_cls_act -> cls_bpf)?
There's another reason I chose netfilter over tc: I need to activate the
filter from a kernel module, hence need an in-kernel (rather than user space)
API.
netfilter provides that via nf_register_net_hook(), I couldn't find
anything similar for tc. And an egress netfilter hook seemed like
an obvious missing feature given the presence of an ingress hook.
The module I need this for is out-of-tree:
https://github.com/RevolutionPi/piControl/commit/da199ccd2099
In my experience the argument that a feature is needed for an out-of-tree
module holds zero value upstream. If there's no in-tree user, the feature
isn't merged, I've seen this more than enough. Which is why I didn't mention
it in the first place.
For our use case I wouldn't even need the nft user space support which I
posted separately, I just implemented it for completeness and to increase
acceptability of the present series.
Thanks,
Lukas
Powered by blists - more mailing lists