OpenFlow从诞生之日起就与SDN划起了等号，时至今日仍然有用户在寻求SDN方案时潜意识在寻求OpenFlow的支持。实际上，随着SDN的逐步演进，软件定义网络更多是一种设计思路与设计理念，SDN网络的设计经历了螺旋式发展。近几年SDN之父Nick教授身体力行的开始改造OpenFlow，网络设备第一次和计算设备一样具有了可编程的能力。和OpenFlow刚刚面世一样，用于网络设备编程的P4编程语言也存在众多误解。本文的主要目的就是解惑P4编程语言的几个常见误区。
误区一：P4就是Openflow2.0
这一误区产生的主要原因是斯坦福大学的Nick Mckeown教授在OpenFlow之后马不停蹄地开始P4的设计与推广，因此很容易让人以为P4就是OpenFlow的新版本。虽然两者之间是超集的关系，但是P4绝不是已经停止更新的OpenFlow新版本。
由ONF组织推动的OpenFlow在发展到1.6版本后停止更新，ONF组织也历经与On.Lab和P4.org两大组织的合并。OpenFlow本身只是SDN南向接口的一种，是控制器向转发设备传递命令的一种方式；而P4 (Programming protocol-independent packet processors)则是一种编写协议无关的包处理器的高级编程语言，它可以令设备实现OpenFlow同样的功能，但是它的愿景远不是仅仅实现更灵活的openflow，它要给予数据平面与计算平面一样无与伦比的可编程性。传统上无论是OpenFlow设备还是非OpenFlow设备大部分都是按照固定流水线执行指令，在芯片现有功能内闪转腾挪而不能越雷池半步。P4语言则是要打破藩篱，让数据平面设备也具备在线实现新功能的能力。尤为与FPGA这种现场可编程门阵列不同的是，FPGA提供的是半定制电路，需要采用VHDL或者Verilog等语言来实现硬件的重构，每个逻辑单元的功能在重编程（烧写）时确定。
所以P4是数通芯片的新一次尝试，与OpenFlow只是定义一个南向接口截然不同。
误区二：只有Tofino芯片可以支持P4
这个误区仍然与Nick教授有很大关系。Nick作为SDN之父在看到OpenFlow面临的诸多落地困局后于2013年的ACM SIGCOM发表《Forwarding Metamorphosis: Fast Programmable Match-Action Processing in Hardware for SDN》一文，并且作为创始人成立了Barefoot公司。因此Barefoot公司推出的Tofino系列芯片天然支持P4。但是一个好汉三个帮，即使Nick宣称可编程的数据芯片存在诸多优点，在商业落地时也面临行业巨头的打压与客户的质疑，因此P4语言并不是Nick或者Barefoot公司的私有产品，它由P4.org社区运作推广，希望借助社区的力量来找到应用场景和市场，近期P4社区刚刚与ONF组织合并。
目前支持P4编程的数据平面芯片既可以是传统的网络处理器（NPU），也可以是上文提到的FPGA芯片，更不用说在CPU上可以模拟P4的各种行为，还有大神在GPU上开展P4的研究工作。
误区三：P4只支持可编程芯片
P4语言并不是学术界灵光闪现的成果，它是业界在OpenFlow的前期探索后的成果，谷歌在其中发挥了重大作用。时至今日谷歌现网仍然有很多运行OpenFlow协议的设备，因此当网络走向可编程走向更加开放，如何利旧就是个现实问题。而P4作为一种语言本身就是对网络行为的描述，所以只要能够让传统非可编程网络芯片可以理解由P4定义的转发流水线就能让传统芯片也支持P4定义的行为。
目前谷歌的SDN网络正在向可编程迈进，传统设备通过抽象层的转译也可以支持P4语言，因此传统厂商支持P4不是不行而是可为不可为的问题，毕竟业界老大哥携压倒性市场份额狂奔在另一条路上。
误区四：P4语言是Python一样的高级语言
P4虽然是高级语言但是属于针对特定领域的DSL语言，它和Python等计算机高级语言相比有很大的差别，首先P4语言需要考虑物理资源的限制，P4最终管控的是资源有限的数据平面转发芯片，所以注定不会像CPU所处的计算平面具有超高的外置Memory资源；也正是这个原因，p4代码并不具备高级语言的通用移植性，在A平台的可运行代码在B平台不一定可以工作，所以每个支持P4语言的厂家都会提供自家产品的架构模型和编译器，用户需要在编译时选择相应物理平台来实现可落地的代码。
P4-16版本推出的目的就是提升目标无关性，通过语言与架构分离和灵活的数据模型支持多种目标设备。
误区五： P4代码就是SDN
如同基于OpenFlow实现的SDN，其最重大的改进是逻辑上的集中控制，在大规模数据中心和WAN网络接入这种全局视角可以更好的解决网络拥塞等传统网络的问题。利用P4来实现可编程的设备，他们完成的也只是数据平面的工作，实现报文的转发流程还需要控制平面的参与。因此在OpenFlow时代诞生了OpenDaylight和ONOS等SDN控制器项目；P4语言的协议独立意味着不会原生支持任何协议，P4语言只是描述报文头部格式以及程序中需要的协议字段。所以并没有解决控制层面的问题。P4优化了数据平面的实现，但是控制层面的工作一点也不能少。
无论是采用传统OSPF/BGP路由协议，或者是沿用SDN控制器都可以实现对P4设备的控制。Opendaylight和ONOS都提供远程控制插件，可以Runtime实现控制流的发送。
P4的诞生是SDN演进的自然结果，如同OpenFlow刚刚出现面临的不解一样，P4作为新生事物也存在一些误区，相信随着P4-16的推出以及P4.org与ONF的合并，P4将获得更多的关注与落地。当然这一切也取决于Intel的态度。
