Edgecore AS9716-32D：PDDF 下 sfputil 把 400G QSFP-DD 模块解析成了 QSFP28
我们正在实验室里把一对 AS9716-32D 组成 400G spine，用的是社区版 SONiC 镜像，带 PDDF 平台层。光模块本身没问题，对端链路正常，但交换机对模块的描述全是错的。
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- 该平台的社区版 SONiC 构建，带 PDDF
- 第一个插槽里插的是400G QSFP-DD模块（NeoPhotonics型号）
读取本身是成功的，模块能被列出来，但插槽被报告为QSFP28：
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonics问题就出在这行Identifier上。这是个QSFP-DD的模块，所以下面的字节是按SFF-8636的字段集去解析的，而不是CMIS的字段集，之后的字段读出来全是乱码。
我已经检查过：
- 模块本身没问题，同一个型号在另一个平台上能正确读出，对端也能看到光；
- 重新插拔或换插槽都没有变化，所有400G端口表现一致；
- 在PDDF设备描述里，这些插槽被声明为QSFP28并绑定到了optoe1。
最后这一点是不是就是全部答案？QSFP-DD插槽是不是就需要一个不同的optoe设备，改平台描述文件是不是被认可的修复方式，还是说上层也需要知道这个插槽的类型？
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
你的症状和这个绑定问题完全吻合，光模块那边不用再查了。
AS9716-32D 的 PDDF 设备描述把400G插槽声明为QSFP28并绑定到了optoe1。optoe1 暴露的是QSFP+和QSFP28使用的SFF-8636 EEPROM布局，所以一个CMIS模块被按错误的映射来读取，Identifier之后的所有内容都是乱码。你看到的端口类型根本不是检测出来的，就是描述文件里写的什么就是什么。
QSFP-DD遵循CMIS，而CMIS由optoe3提供服务。修复方法是把这些插槽在PDDF设备描述里的两个字段都改过来：类型从QSFP28改成QSFP-DD，驱动从optoe1改成optoe3。我在同一台设备上用一个400G的NeoPhotonics模块验证过，改完之后
sfputil show eeprom能正确解析出模块信息了。有两点要提醒。这是平台数据，所以升级镜像会把旧的描述文件覆盖回去，除非这个改动本身就写进了你构建的镜像里。另外，上游确实有人提交过完全一样的改动并且被批准了，但那个PR最后被关闭而没有合并，相关工作被并入了后续的一个改动里，所以不要想当然地以为你的镜像已经带了这个修复。先去读一下你这个平台的设备描述文件，一分钟内就能知道你是不是在追一个根本不存在的问题。
在动任何平台文件之前，先贴出原始dump：对那个端口跑一下
sudo sfputil show eeprom -d。如果所有字节都在，只是解析方式不对，那就是绑定问题而不是模块问题，这个区分值得花十分钟先搞清楚，再谈什么RMA。另一半你自己其实已经答出来了。optoe1是QSFP+和QSFP28用的SFF-8636风格，一个CMIS模块用它来读，从Identifier开始就会全乱掉，这正是你贴出来的那个输出。一旦描述文件把QSFP-DD插槽标成了optoe1，模块那一侧就没什么好怀疑的了。
所以也贴一下这些插槽对应的PDDF设备描述的相关行。这样能看出到底只是驱动字段错了，还是连声明的插槽类型也错了。
就是这个问题。插槽类型改成QSFP-DD，驱动改成optoe3，reload之后模块现在能正确解析了，
sfputil show eeprom也不再把插槽叫做QSFP28。我把这个改动放进了我们构建的镜像里，而不是直接改运行中的交换机，正是因为前面提到的升级会覆盖的问题。给以后看到这个帖子的人说句实话：这只是修复了EEPROM怎么被读取，仅此而已。这个平台上其余的光模块相关逻辑还有它自己的怪癖，我不会说这台设备已经完全搞定了。
既然你提到了剩下的怪癖，这里有一个在同一平台上等着你的问题。我们的AS9716-32D (x86_64-accton_as9716_32d-r0)跑的是SONiC master构建，
sudo sfputil show presence把插了模块的端口都列为Present，EEPROM也能正常读取，而show interfaces transceiver presence却把每个端口都报告为Not present。syslog里反复出现：通过CLI读取EEPROM则会报RuntimeError('PddfEeprom is not Programmed')。这个问题在重启之后随机出现，也一直没人给出根因分析，所以在那台设备上我只信sfputil的presence结果。
一个不太相关但同一个区域的问题：这两条命令在202012分支上对字段名称的叫法也存在分歧，202205分支里已经清理过了。如果你的输出只是措辞不同、内容一致，那基本上就是这个原因。