On Wed, 2007-28-02 at 23:30 -0800, David Miller wrote: > That would be perfect for new applications. > But we have to support all the old ones, so we're stuck > providing correctly functioning AF_PACKET handling on > all devices, sorry. > It also breaks all the ingress tc code by making that change. The two scenarios i see in respect to performance are: - run a sniffer and you will see a substantial performance degradation as the pps goes up. There is no rocket science to that. This has nothing to do with bridging and will happen still even if that patch went in. - dont run any tap with the current codepath and you still see the _substantial_ performance drop then we have an opportunity to optimize. Not _by avoiding the code_ as in Stephens patch but by tunning that tap code path. [For example, you should still see a _tiny_ performance degradation if you turned on TC actions on ingress at compile time but had zero policies at run time - but that code path has been reduce to a single compare]. > And in fact that effectively makes the new socket option > pointless, since it doesn't buy us anything since we have > to support the old stuff fully anyways. agreed. I have been tied up elsewhere so havent been following netdev closely: There seem to be complaints of bridging performance going down in recent kernels - or is that someone misconfiguring their drivers? cheers, jamal _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/bridge
