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: > > 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@xxxxxxxxx/ So what's the consensus? Shall I post a non-RFC version, rebased on current nf-next/master? Thanks! Lukas
