Intel 推出 DPDK 开发包的意义是什么？
http://www.zhihu.com/question/27413080?sort=created
基于intel dpdk的包处理器，相较于基于内核网络协议栈的包处理器，优势和价值在哪里？
基于dpdk的包处理性能，是否会比基于内核协议栈高，如果高会高多少，内核网络协议栈的瓶颈又主要在哪里？
市场
一句话：Intel推出dpdk，就是为了让自己的硬件产品卖得更好。
功能多了，灵活度高了，性能又不赖，谁不愿意买哟？
dpdk只适合在x86平台下使用，其达到相当高的性能水平，仰赖的也完全是Intel硬件内部的独特机制（详情参照楼上技术剖析）。这非常明显地抬高了Intel硬件产品的身价。
这应该是Intel的主要目的。
需求
dpdk在我目前关注的领域（IP的做，非IP的也做；未来三五年的技术验证做，未来三五十年的概念原型也做），主要是用于开发内核尚不具备的新功能。就更新速度而言，内核更新慢，基于dpdk的网络功能更新快。
将一种新的网络功能写入内核并纳入发行版linux，需要较为复杂的调试和完善过程。一般要求该功能已经相当成熟可靠，且复杂度不高，适合在内核中运行。
而dpdk为厂商提供了更广阔的发挥空间，可以说很好地推动了新机制、新技术的试验和改良
首先dpdk总的来说是一个2层的东西，也就是说本来驱动做的事情放到用户层来做了，并且根据体系结构提供了各种各样的优化，一般只用来做IO，当然也提供了很多3层的库，转发的库，lpm的库等，dpdk并没有提供开源的高性能tcp/ip协议栈。
不清楚楼主说的基于内核协议栈的包处理器具体指什么，如果是指linux内核本身的协议栈的话，其实主要还是兼容性和通用性。当然也有一些硬件实现的Tcp offline engine，但是受限于硬件网卡内存的限制，在tcp的并发量和性能上并不会比基于dpdk的高。
至于具体性能，其实是可以量化的，10Gbps ，64bytes包长，如果一个包的处理时间大于67ns，那么肯定会丢包，也就是说所有处理基本只能全部在cache里，长时间稳定的不丢包还是很难做到的。
至于dpdk的轮询机制，不管有没有包，cpu都是100%，一旦收包的这个线程绑定的cpu被别的线程抢占，那么性能会大幅度下降。
dpdk高性能限制非常非常多，配置也基本无法通用，要充分考虑numa+nuio等各种体系结构，一旦cpu配置错了，性能渣得要死。
dpdk出来之前，也有很多类似的解决方案，基本原理都是大同小异，ioengine，netmap，ntop 10g系列。
不过dpdk和他们相比性能上没有多大优势，配置和操作上比他们都复杂的多，不稳定性也大，但是dpdk有一个他们没法比的巨大优势，就是dpdk支持几乎所有intel 网卡，包括最新出的网卡。如果过几年不想在你的驱动程序里手动添加新的intel网卡支持，那么选择dpdk没错的。
还有一个，就是可以用gdb调试了。
首先，DPDK和内核网络协议栈不是对等的概念。
DPDK只是单纯的从驱动拿数据，然后组织成数据块给人用，跑在用户态。功能相当于linux的设备无关接口层，处于socket之下，驱动之上。只不过linux协议栈的这部分在核心态。
你说的包处理器，很多时候是不用linux内核协议栈的，而是用专用包处理程序，类似于DPDK加上层应用处理。通常会有些硬件加速器，包处理效率更高些。缺点是一旦用不上某些功能，那些加速器就白费了。而纯软件处理就非常灵活，不过代价就是功耗和性能。
纯DPDK性能非常高，intel自己给出的数据是，处理一个包80时钟周期。一个3.6Ghz的单核双线程至强，64字节小包，纯转发能力超过90Mpps，也就是每秒9千万包。
不知你有没有看出来，80周期是一个非常惊人的数字？正常情况下，处理器访问一下ddr3内存都需要200个周期，而包处理程序所需要操作的数据，是从pcie设备送到ddr内存的，然后再由处理器读出来，也就是说，通常至少需要200周期。为啥现在80周期就能完成所有处理？我查了下文档，发现原因是使用了stashing或者叫direct cache access技术，对于PCIe网卡发过来的包，会存在一个特殊字段。x86的pcie控制器看到这个字段后，会把包头自动塞到处理器的缓存，无序处理器来干预。由于包头肯定是会被读取的，这样相当于提前预测，访问的时间大大缩短。
如果加上linux socket协议栈，比如跑个纯http包反弹，那么根据我的测量，会掉到3000-4000周期处理一个包，单核双线程在2.4Mpps，每秒两百四十万包，性能差40倍。
性能高在哪？关键一点，DPDK并没有做socket层的协议处理，当然快。其他的，主要是使用轮询替代中断，还有避免核心态到用户态拷贝，并绑定核，避免线程切换开销，还有避免进入系统调用的开销，使用巨页等。
还有很关键的一点，当线程数大于12的时候，使用linux协议栈会遇到互斥的瓶颈，用性能工具看的话，你会发现大部分的时间消耗在spin_lock上。解决方法之一是如github上面的fastsocket，改写内核协议栈，使包始终在一个核上处理，避免竞争等。缺点是需要经常自己改协议栈，且应用程序兼容性不够。
另外一个方法是使用虚拟机，每个特征流只在一个核处理，并用虚拟机隔绝竞争，底层用dpdk做转发，上层用虚拟机做包处理，这样保证了原生的linux协议栈被调用，做到完全兼容应用程序。不过这种方法好像还没有人做成开源的，最近似的是dpdk+虚拟交换机ovs的一个项目。
如果你只想要dpdk的高性能加tcp/ip/udp的处理，不考虑兼容性，那么还可以去买商业代码，我看了下供应商的网站介绍，纯转发性能大概在500-1000周期左右一个包。