继续讨论van的channel

目前有三处相关的信息，一个是Van自己的presentation，在lwn上一篇比较深入的文章，另外还有一个blog讨论了这个问题。
Van的channel在提高linux TCP/IP协议栈的性能方面做了这样的工作：打破传统分层的TCP/IP设计架构，将IP包直接送达至目的地，好象是一条快速通道，Channel因此 而得名（但据lwn说，channel是指一种设计良好的环形buf，对它的读写不需要锁，而且对Cache非常友好，这么说也有道理，显然这么一种 buf是这个新框架所必须的）。这么做消除了多种开销，包括：

• 当channel在应用层实现时，数据包从内核空间到用户空间的拷贝不再需要，而是通过内存映射将内核收到的数据直接映射到应用程序的地址空间。（这个buf的实现很有点意思）


• 当channel在驱动实现时，不再需要skbuf（文物啊）来保存收到的报文，而是直接把报文丢到一个channel（一个环行buf）里。


• 各种运行环境切换的开销（硬中断、软中断、系统调用）


• Cache不命中的概率大幅降低，对smp更加友好

还有一点是不太明显的。有个“端到端原则”这样说道：要尽量把工作在网络的边界完成，网络本身只做尽可能少的工作。TCP就是这个原则的体现，可靠传输、流量控制、拥塞控制由连接的两个端点完成，网络只负责传输包，仅此而已。
但是诸位可能没注意到，我们目前的tcp协议栈并没有彻底贯彻这一原则，数据包被交给了协议栈，而不是交给了需要该数据包的程序，而这个程序才是真正的边 界。由于协议栈的处理所引入的包括延迟、丢包等情况使得应用程序无法看到真实的网络状况，这将导致无法有效的实施控制。比如TCP协议对RRT的计算会因 为报文在协议栈各层的排队、softirq的延迟而失真，会导致TCP吞吐量的下降。所以当Channel把报文直接送到应用程序时，才有可能实现高性能 的网络协议。

请注意有趣的一点，当channel一直通到应用程序时，需要在应用层实现TCP协议。

Channel对传统TCP协议栈性能的提升是巨大的，但同时对框架的改动也是根本性的，一些依赖于传统架构的应用不得不改写，包括被广泛使用的netfilter。
还有一个问题，就目前Channel的信息被遮遮掩掩的情况来看，这东西的license肯定有问题。而lwn上也有人向Van证实了这一点。 Channelized Driver和Channelized socket都会以GPL形式开放出来，但是channelized Application所需要的应用层TCP协议栈却由于某种原因无法GPL之。