首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >关于P4编程语言的几个误区

关于P4编程语言的几个误区

作者头像
SDNLAB
发布2019-06-21 16:57:28
1.6K0
发布2019-06-21 16:57:28
举报
文章被收录于专栏:SDNLABSDNLAB

作者简介:张渐修,任职于上海同悦信息科技有限公司从事SDN/P4交换机的市场推广工作。vx:Tooyumzjx

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的态度。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-06-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 SDNLAB 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档