SONiC dekoduje CMIS 4.0 QSFP-DD na zniekształcone pola vendora, podczas gdy moduły SFF parsują się poprawnie

Na jakiej gałęzi jesteś? Są znane niespójności nazw kluczy między show interfaces transceiver eeprom a sfputil w 202012, które zostały ogarnięte w 202205, i warto to wykluczyć, zanim zaczniesz kopać głębiej.

Wklej wynik sudo sfputil show eeprom -d dla tego samego portu. Jeśli sfputil daje ci te same zniekształcone ciągi, usterka jest we wspólnej ścieżce dekodowania. Jeśli zamiast tego wywala błąd, jesteś w innym terytorium - mamy platformy, gdzie po prostu odpowiada Cannot get Module EEPROM data: Invalid argument i nigdy nie dochodzi do dekodowania czegokolwiek.

Odpaliłem oba: sudo sfputil show eeprom -d i show interfaces transceiver eeprom -d na tym samym porcie. Identyczne zniekształcenie, te same pola, te same śmieci tam, gdzie powinien być numer seryjny. Żadnego Invalid argument nigdzie, sam odczyt przechodzi bez zastrzeżeń.

Czyli obie komendy zgadzają się ze sobą, tylko zgadzają się na złej odpowiedzi. Sąsiednie porty QSFP28 zostają czyste w obu, co sprawia, że wygląda to na coś specyficznego dla tej części CMIS, a nie dla platformy.

Ten wzorzec to podpis parsera zastosowanego do mapy pamięci, której nie rozumie: part number siedzący w polu nazwy vendora, nieczytelny numer seryjny, przesunięte connector i encoding. Zepsuty moduł albo zepsuty odczyt I2C dają błąd albo blok zer, a nie schludnie błędne ciągi.

Ścieżka dekodowania siedzi w sonic_platform_base/sonic_sfp/sfputilbase.py, i tam te trzy ciągi tożsamości są zdejmowane z offsetów zaszytych na sztywno względem starszej mapy SFF, cokolwiek by nie było podłączone. CMIS 4.0 QSFP-DD nie trzyma swojego bloku tożsamości pod tymi adresami - spec CMIS 4.0 opisuje to w sekcji 8.3 - więc kod czyta prawdziwe bajty z właściwego modułu, tylko nie te, które sądzi, że czyta, i drukuje cokolwiek zajmuje ten zakres. Dlatego też nic nigdy nie failuje czysto: żaden krok nie patrzy na bajt identyfikatora i nie przełącza się na układ CMIS.

Praktyczny wniosek jest taki, że nic poniżej parsera, który rozumie mapę CMIS, nie zrobi tego dobrze, a dopóki to nie wyląduje w twojej gałęzi, wynik CLI dla tej części nie jest klasy inwentaryzacyjnej. Do bazy zasobów czytaj strony surowo i dekoduj je sam, zamiast skrobać CLI.

Do surowego odczytu chcesz sterownika optoe: wystawia EEPROM-y SFP, QSFP i CMIS do bezpośredniego odczytu i zapisu, więc możesz wyciągnąć bajty i zdekodować je we własnym skrypcie. To jedyne, czym na razie karmiłbym bazę zasobów dla części CMIS.

Jedno ostrzeżenie, jeśli szukasz offsetów. Tabela, którą wszyscy cytują, to ta SFF - A0h bajty 20-35 na nazwę vendora, 40-59 na PN, rev i SN. To dokładnie te offsety, które produkują twoje śmieci na module CMIS, więc nie używaj ich tam ponownie. Ta sama ostrożność na hoście Linux jako narzędziu na stole: ethtool -m do widoku zdekodowanego i ethtool -e do surowych bajtów są w porządku dla części SFP, ale sprawdź, co twój build faktycznie rozumie, zanim zaufasz polom, które drukuje dla CMIS.

Obsługa CMIS jest cienka w więcej miejscach niż tylko dekoder EEPROM. Wstawiliśmy do eksploatacji tacę optyki InnoLight 800G QSFP-DD, T-DP8CNH-NNO i T-DP8CNT-NNO, i mniej więcej co drugie włożenie zostawiało nas z martwym portem: datapathy zgłaszały DataPathDeactivated, log niósł timeout dla 'ConfigSuccess', a stamtąd port był down na stałe - żadnego retry, nic, co przywróciłoby go samo.

Winowajca okazał się decommission_all_datapaths() w cmis.py. Przechodzi całą sekwencję jedno po drugim - DEINIT, application ID wyzerowany do 0, potem INIT - i nigdy nie sprawdza, czy krok faktycznie zadziałał, zanim zacznie następny. Nasze części potrzebują dokładnie tego potwierdzenia, więc datapath zostaje na wpół skonfigurowany, a maszyna stanów po prostu wysiaduje swój timer. Prawdziwa poprawka musi czekać asynchronicznie, bo nie można blokować wewnątrz inline'owej maszyny stanów CMIS w xcvrd, i ostatnio jak sprawdzałem, nikt takiej nie wylądował. Inny bug, ten sam motyw: ścieżka CMIS doczepiona do kodu napisanego pod części SFF.

Jedna korekta do kierunku, w który to dryfuje, bo te dwa tryby awarii ciągle się ze sobą mieszają. Cannot get Module EEPROM data: Invalid argument, albo QSFP znikający z sfputil po cyklu zasilania, dopóki sterownik nie zostanie naprawiony, albo platforma, która po prostu nie implementuje get_transceiver_info - to są luki platformy i sterownika, i zatrzymują cię, zanim dojdzie do jakiegokolwiek dekodowania.

To, co jest opisane tutaj, to coś odwrotnego: kompletny, udany odczyt, który potem jest interpretowany z złym układem pól. Nie wymieniaj modułów ani nie goń wersji sterownika przez to. Bajty wewnątrz tego modułu są w porządku, a każde narzędzie, które zdekoduje je jako CMIS, pokaże ci numer seryjny z etykiety.