Linux Ethernet Bridging - Mar 2018 - [Bridge] [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter

On Fri, 2015-03-06 at 17:37 +0100, Florian Westphal
wrote:
> 
> > > I did performance measurements in the following way:
> > >?
> > > Removed those pieces of the packet pipeline that I don't
necessarily
> > > need one-by-one.? Then measured their effect on small packet
> > > performance.
> > >?
> > > This was the only part that produced considerable effect.
> > >?
> > > The pure speculation was about why the effect is more than 15%
> > > increase in packet throughput, although the code path avoided
> > > contains way less code than 15% of the packet pipeline.? It
seems,
> > > Felix Fietkau profiled similar changes, and found my guess well
> > > founded.
> > >?
> > > Now could anybody explain me what else is wrong with my patch?
> >?
> > We have to come up with a more generic solution for this.
> 
> Jiri Benc suggested to allowing to attach netfilter hooks e.g. via tc
> action, maybe that would be an option worth investigating.
> 
> Then you could for instance add filtering rules only to the bridge port
> that needs it.
> 
> > These sysfs tweaks you're proposing look to me like an obscure way
to
> > tune this.
> 
> I agree, adding more tunables isn't all that helpful, in the past this
> only helped to prolong the problem.
How feasible would it be to make it completely dynamic?

A given hook could automatically disable itself (for a given device) if
the result of running it the first time was *tautologically* false for
that device (i.e. regardless of the packet itself, or anything else).

The hook would need to be automatically re-enabled if the rule chain
ever changes (and might subsequently disable itself again).

Is that something that's worth exploring for the general case?

Eschewing a 15% speedup on the basis that "well, even though we've had
three of these already for a decade, we're worried that adding a fourth
might open the floodgates to further patches" does seem a little odd to
me, FWIW.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL:
<http://lists.linuxfoundation.org/pipermail/bridge/attachments/20180309/b3ef91ec/attachment-0001.bin>

From: David Woodhouse <dwmw2 at infradead.org>
Date: Fri, 09 Mar 2018 15:31:15 +0000
> Eschewing a 15% speedup on the basis that "well, even though we've
had
> three of these already for a decade, we're worried that adding a fourth
> might open the floodgates to further patches" does seem a little odd
to
> me, FWIW.
The cost we are dealing with is a fundamental one which is a result of
the hook design.

Indirect calls are killer.

Indirect calls are even more killer now in the age of Spectre and
retpolines.

I definitely would rather see the fundamental issue addressed rather
than poking at it randomly with knobs for this case and that.

Thank you.

David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> 
> On Fri, 2015-03-06 at 17:37 +0100, Florian Westphal wrote:
> > 
> > > > I did performance measurements in the following way:
> > > >?
> > > > Removed those pieces of the packet pipeline that I don't
necessarily
> > > > need one-by-one.? Then measured their effect on small packet
> > > > performance.
> > > >?
> > > > This was the only part that produced considerable effect.
> > > >?
> > > > The pure speculation was about why the effect is more than
15%
> > > > increase in packet throughput, although the code path
avoided
> > > > contains way less code than 15% of the packet pipeline.? It
seems,
> > > > Felix Fietkau profiled similar changes, and found my guess
well
> > > > founded.
> > > >?
> > > > Now could anybody explain me what else is wrong with my
patch?
> > >?
> > > We have to come up with a more generic solution for this.
> > 
> > Jiri Benc suggested to allowing to attach netfilter hooks e.g. via tc
> > action, maybe that would be an option worth investigating.
> > 
> > Then you could for instance add filtering rules only to the bridge
port
> > that needs it.
> > 
> > > These sysfs tweaks you're proposing look to me like an
obscure way to
> > > tune this.
> > 
> > I agree, adding more tunables isn't all that helpful, in the past
this
> > only helped to prolong the problem.
> 
> How feasible would it be to make it completely dynamic?
> 
> A given hook could automatically disable itself (for a given device) if
> the result of running it the first time was *tautologically* false for
> that device (i.e. regardless of the packet itself, or anything else).
> 
> The hook would need to be automatically re-enabled if the rule chain
> ever changes (and might subsequently disable itself again).
> 
> Is that something that's worth exploring for the general case?
AF_BRIDGE hooks sit in the net namespace, so its enough for
one bridge to request filtering to bring in the hook overhead for all
bridges in the same netns.

Alternatives:
- place the bridges that need filtering in different netns
- use tc ingress for filtering
- use nftables ingress hook for filtering (it sits in almost same
  location as tc ingress hook) to attach the ruleset to those bridge
  ports that need packet filtering.

(The original request came from user with tons of bridges where only
 one single bridge needed filtering).

One alternative I see is to place the bridge hooks into the
bridge device (net_bridge struct, which is in netdev private area).

But, as you already mentioned we would need to annotate the hooks
to figure out which device(s) they are for.

This sounds rather fragile to me, so i would just use nft ingress:

#!/sbin/nft -f

table netdev ingress {
  chain in_public { type filter hook ingress device eth0 priority 0;
   ip saddr 192.168.0.1 counter
 }
}