> > There are actually some non-trivial issues wrt. this. We would > need to loop inside of the packet scheduler, and netfilter, to do > correct traffic classification and firewalling.
It could be introduced slowly, with some compat code that just falls back to packet at a time mode (like it has been done with netfilter for non linear skbs for a long time). At the beginning just the fast path counts. I like this also because it has the chance to lower lock and atomic instruction overhead. e.g. when you have a train of packets from all the same device you could do a "bulk" atomic_add and sub on the device counters and only take the various locks once. Andrew used to introduce such tricks into the VM and it helped quite a lot for some loads. > > But I guess we could deal with that by supporting chaining in > those subsystems. It looks ugly though, what to do if the > first packet is marked as "delay" by the packet scheduler, > but the rest are allowed to pass through to the device right > now? Do we unlink the one which will be delayed? Why not? If quick unlinking is a problem something would be wrong with the design. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
