Reconsidering network channels

Since then, however, reality has begun to make itself felt - something which reality is wont to do, sooner or later. Which is why David Miller's latest pronouncement on network channels reads like this:

The issue at hand had to do with the integration of channels and netfilter. The hope had been that packets could be identified and sorted into their respective channels before the netfilter (firewall) processing was done. Then said processing could be performed close to the application, on the same processor. It turns out, however, that netfilter can change the real destination of the packet. So packets must be filtered before entering a channel, and much of the performance benefit of using a channel is lost.

Alexey Kuznetsov has posted a detailed criticism of channels, asserting that most of the claimed benefits are illusory. Says Alexey:

Finally, it seems that many of the benefits of channels can be had by carefully taking advantage of the capabilities of modern hardware. In particular, an increasing number of devices can perform simple packet classification and (via targeted interrupts) direct packets to the CPU where the destination application is running. That technique will get rid of the cache misses caused by performing interrupt processing on one processor and protocol processing on another.

In the end, it appears that yet another seemingly bright scheme may not make the transition into real-world deployments. Some of its core concepts, such as using cache-friendly data structures and trying (even harder) to improve cache locality, will likely influence the future direction of the network stack, however. So, while there may not be a revolutionary new mechanism in the network stack's future, some of the promised performance improvements should eventually be realized anyway. And, as David says, "At least, there is less code to write."