NFV 利器 FD.io VPP

在VPP中，报文以向量批处理的形式在节点之间以流水线的方式处理，可以更加高效的利用CPU的i-cache，节点可以动态生成并加入到转发图中，节点分为多种类型，如VLIB_NODE_TYPE_INPUT，为输入节点。可以按照VPP的框架自定义节点如：

其中最重要的是回调函数snat_out2in_node_fn与next_nodes数组，snat_out2in_node_fn代表当数据包进入本node中，node对于一组数据包具体的处理过程。而next_nodes数组则表示该node执行完毕后，选择执行的下一个节点，在该选择上本地node节点有绝对的控制权。于是疑问就出现了，在上述的node定义结构体中并没有选择该本地node输入节点的接口。

在vpp中的L3实现中，利用feature框架完成了一个三层转发子图。该子图的初始节点为ip4-input，终止节点为ip4-lookup，其中子图实现的功能有ip4-acl、ip4-source-check等，其作用为执行数据包进入L3 但在转发forward之前的一些列的L3动作，例如snat的功能在这个子图中完成。典型的注册如下所示:

而snat node输入node的定义则利用了L3 feature框架

最终L3 node的全貌如下：

其中runs_before表明该node的动态下一个节点，而在上述node结构体定义中的next_nodes则为该节点的静态下一个节点。而该node的输入节点则由rx_feature_out2in的值决定，而该值则是有方向的，即网卡的收报方向；换而言之只有从相应的网卡收报才会进入到本地的node处理中，于是利用该特性就可以获取到本地node的输入节点。可以用命令行vppctl show ip features显示。有了FD.io VPP这样相对成熟的框架我们就可以把Neutron中的dataplane组件用VNF来实现，不仅可以获取高性能还避免了用DPDK完全开发，大大减少了工作量，不失为一种很好的Neutron datapl