SONiC, CMIS 4.0 QSFP-DD'yi bozuk vendor alanlarına çözümlüyor, SFF modülleri ise sorunsuz parse ediliyor

Hangi branch'tesin? 202012'de show interfaces transceiver eeprom ile sfputil arasında bilinen key-name tutarsızlıkları var, bunlar 202205'te giderildi; daha derine inmeden önce bunu ekarte etmekte fayda var.

Aynı port için sudo sfputil show eeprom -d çıktısını paylaş. sfputil sana aynı bozuk string'leri veriyorsa sorun paylaşılan decode yolunda demektir. Bunun yerine hata veriyorsa farklı bir bölgedesin - bizde tam da Cannot get Module EEPROM data: Invalid argument diye cevap verip hiçbir şeyi çözümlemeye başlamadığı platformlar var.

Aynı portta ikisini de çalıştırdım: sudo sfputil show eeprom -d ve show interfaces transceiver eeprom -d. Aynı bozulma, aynı alanlar, serinin olması gereken yerde aynı çöp. Hiçbir yerde Invalid argument yok, okumanın kendisi sorunsuz geçiyor.

Yani iki komut birbiriyle aynı fikirde, sadece yanlış cevapta hemfikirler. Komşu QSFP28 portları ikisinde de temiz kalıyor, bu da meselenin platformdan çok bu CMIS parçasına özgü olduğunu düşündürüyor.

Bu örüntü, anlamadığı bir bellek haritasına uygulanan bir parser'ın imzası: vendor name alanında oturan bir part number, okunamayan bir seri, kaymış connector ve encoding. Bozuk bir modül ya da bozuk bir I2C okuması sana bir hata ya da bir blok sıfır verir, böyle düzgünce yanlış string'ler vermez.

Decode yolu sonic_platform_base/sonic_sfp/sfputilbase.py içinde yaşıyor, orada üç identity string'i, karşıda ne takılı olursa olsun, legacy SFF haritasına göre sabitlenmiş offset'lerden alınıyor. CMIS 4.0 bir QSFP-DD identity bloğunu o adreslerde tutmuyor - CMIS 4.0 spesifikasyonu bunu bölüm 8.3'te tanımlıyor - yani kod doğru modülden gerçek byte'lar okuyor, sadece okuduğunu sandığı byte'lar değil, ve o aralıkta ne varsa onu yazdırıyor. Hiçbir şeyin düzgünce fail etmemesinin sebebi de bu: hiçbir adım identifier byte'ına bakıp bir CMIS layout'a geçmiyor.

Pratikteki sonuç şu: CMIS haritasını anlayan bir parser'dan azı bunu doğru yapmayacak, bu senin branch'ine düşene kadar da bu parça için CLI çıktısı envanter kalitesinde değil. Asset veritabanı için sayfaları ham okuyup CLI'yi kazımak yerine kendin çözümle.

Ham okuma için istediğin şey optoe driver'ı: SFP, QSFP ve CMIS EEPROM'larını doğrudan okuma ve yazma için açığa çıkarıyor, yani byte'ları çekip kendi script'inde çözümleyebilirsin. Şu an CMIS parçaları için asset veritabanına besleyeceğim tek şey bu.

Offset ararken bir uyarı: herkesin alıntıladığı tablo SFF tablosu - vendor name için A0h byte 20-35, PN, rev ve SN için 40-59. Bunlar tam olarak bir CMIS modülünde sana çöp veren offset'ler, orada onları tekrar kullanma. Bench aracı olarak bir Linux host'ta da aynı dikkat geçerli: decode edilmiş görünüm için ethtool -m, ham byte'lar için ethtool -e SFP parçaları için iyi çalışıyor, ama CMIS için yazdırdığı alanlara güvenmeden önce build'inin gerçekte neyi anladığını kontrol et.

CMIS handling, EEPROM decoder'dan daha fazla yerde zayıf kalıyor. Bir tepsi InnoLight 800G QSFP-DD optiğini servise aldık, T-DP8CNH-NNO ve T-DP8CNT-NNO, ve yaklaşık her ikinci takışta elimizde ölü bir port kaldı: datapath'ler DataPathDeactivated raporladı, logda 'ConfigSuccess' için bir timeout vardı ve o noktadan sonra port kalıcı olarak down kaldı - ne retry, ne de kendi kendine geri gelen bir şey.

Suçlu, cmis.py içindeki decommission_all_datapaths() çıktı. Bütün sekansı art arda yürütüyor - DEINIT, application ID'nin 0'a temizlenmesi, sonra INIT - ve bir sonraki adıma geçmeden önce bir adımın gerçekten etkili olup olmadığını hiç kontrol etmiyor. Bizim parçalarımız tam olarak bu doğrulamaya ihtiyaç duyuyor, bu yüzden datapath yarı yapılandırılmış kalıyor ve state machine timer'ını durduk yere bekliyor. Gerçek bir düzeltmenin asenkron beklemesi gerekiyor, çünkü xcvrd'nin satır içi CMIS state machine'inin içinde bloklayamazsın, son baktığımda da kimse bunu merge etmemişti. Farklı bug, aynı tema: SFF parçaları için yazılmış kodun üzerine cıvatalanmış bir CMIS yolu.

Bunun sürüklendiği yöne bir düzeltme, çünkü bu iki hata modu sürekli birbirine karıştırılıyor. Cannot get Module EEPROM data: Invalid argument, ya da bir power cycle'dan sonra driver düzeltilene kadar sfputil'den kaybolan bir QSFP, ya da get_transceiver_info'yu hiç implement etmeyen bir platform - bunlar platform ve driver açıkları, ve herhangi bir decode işlemi başlamadan seni durdururlar.

Burada anlatılan bunun tam tersi: tam, başarılı bir okumanın ardından yanlış alan düzeniyle yorumlanması. Bunun için modül değiştirme ya da driver sürümü kovalama. O modülün içindeki byte'lar gayet iyi, ve onları CMIS olarak çözümleyen herhangi bir araç sana etikette yazan seriyi gösterecektir.