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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
