On Thu, Nov 07, 2019 at 11:51:49PM +0100, Pablo Neira Ayuso wrote:

On Thu, Oct 31, 2019 at 02:41:00PM +0100, Lukas Wunner wrote:

quoted

Introduce a netfilter egress hook to complement the existing ingress hook.

User space support for nft is submitted in a separate patch.

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.  A bit of googling reveals that more
people have expressed a desire for egress filtering in the past:

https://www.spinics.net/lists/netfilter/msg50038.html
https://unix.stackexchange.com/questions/512371

I am first performing traffic control with sch_handle_egress() before
performing filtering with nf_egress().  That order is identical to
ingress processing.  I'm wondering whether an inverse order would be
more logical or more beneficial.  Among other things it would allow
marking packets with netfilter on egress before performing traffic
control based on that mark.  Thoughts?

Would you provide some numbers on the performance impact for this new
hook?

Just a gentle ping for this series.  I'd still be very interested to
get it upstream.  When posting the above-quoted RFC, Daniel NAK'ed it
saying that "weak justification" was provided "for something that sits
in critical fastpath".

However I followed up with numbers showing that the series actually
results in a speedup rather than a slowdown if the feature isn't used:

https://lore.kernel.org/netfilter-devel/20191123131108.dlnrbutabh5i55ix@wunner.de/ (local)

So what's the consensus?  Shall I post a non-RFC version, rebased on
current nf-next/master?

Thanks!

Lukas