It's a start. What's happening there is just parsing the first page (SFP) or the first couple of pages (QSFP) as per the various SFF standards. Take a look at Test 2.3 from the Interop Test Plan rev 20: http://www.opencompute.org/wiki/Networking/SpecsAndDesigns#Pluggable_Transceiver_and_Host_Compliance_and_Interopability_Test_Plan for more information.
What I'm getting at are the 'non-standard' pages that may exist on the device that only the module vendors know about. Today, it's possible to detect and retrieve some of those pages on certain modules, but we do not have the decoder ring to make sense out of it (additional diag info, telemetry data, ability to update firmware, etc...). That decoder ring, as you can imagine, is currently propriety and contained at the module vendor. What I'm envisioning is having a common utility and API to: * query/retrieve additional pages * pass said pages off to a vendor specific decoder ring (each vendor owns their own decoder ring) * decoder ring parses the info and passes it back to the utility * the utility consumes the data (i.e. output to the screen for the user) +--+ Carlos On Thu, Oct 15, 2015 at 9:18 AM, Rob Sherwood <rob.sherw...@bigswitch.com> wrote: > (thanks JeffT for the quick patch: > > https://github.com/opennetworklinux/ONLP/commit/e151905883d5b0f50b5eca67aad4279850948bfe > ) > > This is kind of what I was thinking of: is this what you had in mind > Carlos? > > root@as5710-t:~# ./onlpdump -S > Port Type Media Status Len Vendor Model > S/N > ---- -------------- ------ ------ ----- ---------------- > ---------------- ---------------- > 0 NONE > 1 NONE > 2 NONE > 3 NONE > 4 NONE > 5 NONE > 6 NONE > 7 NONE > 8 NONE > 9 NONE > 10 NONE > 11 NONE > 12 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40508D0383 > 13 NONE > 14 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40508D0271 > 15 NONE > 16 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40508D0518 > 17 NONE > 18 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40212D0185 > 19 NONE > 20 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40508D0398 > 21 NONE > 22 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40508D0250 > 23 NONE > 24 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40508D0406 > 25 NONE > 26 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40212D0232 > 27 NONE > 28 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40508D0230 > 29 NONE > 30 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40212D0168 > 31 NONE > 32 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40212D0164 > 33 NONE > 34 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS31114D0003 > 35 NONE > 36 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40212D0193 > 37 NONE > 38 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40508D0359 > 39 NONE > 40 10GBASE-CR Copper X 0m > C9999-1M-P-LC 1305300044 > 41 NONE > 42 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40212D0171 > 43 NONE > 44 10GBASE-CR Copper X 1m FiberStore > 10GSFP-PC-30-1 FS40508D0258 > 45 NONE > 46 10GBASE-CR Copper X 3m OEM > SFP-H10GB-CU3M CSC31A70001 > 47 NONE > 48 NONE > 49 NONE > 50 NONE > 51 NONE > 52 NONE > 53 NONE > root@as5710-t:~# > > On Wed, Oct 14, 2015 at 6:15 PM, Rob Sherwood <rob.sherw...@bigswitch.com> > wrote: > >> Hi Dustin and Carlos, >> >> I definitely agree that it's a good idea to have such a tool -- to the >> point where that's what we wrote with onlpdump :-) Looking over the code, >> it looks like we don't do the final conversion by default: we have the >> ability to pull the eeprom data in a platform independent way with the >> onlp_sfp_eeprom_read() >> API and the SFF libraries to parse/decode them (see >> https://github.com/opennetworklinux/ONLP/tree/master/modules/sff/module/src >> and >> https://github.com/opennetworklinux/ONLP/blob/master/modules/sff/module/inc/sff/sff.h#L245), >> but it looks like there isn't an easy command-line option to do both. Give >> us a couple of days and we can add that. >> >> What else were you looking for in such a tool? >> >> - Rob >> . >> >> On Wed, Oct 14, 2015 at 2:37 PM, Dustin Byford < >> dus...@cumulusnetworks.com> wrote: >> >>> Hi Carlos, >>> >>> On Wed Oct 14 12:09, Carlos Cardenas wrote: >>> > For those that were present during the Eng. Workshop in Boston at >>> Fidelity >>> > last week (http://www.opencompute.org/wiki/Networking/Workshop-2015-09 >>> ), >>> > you heard a brief point of what we would like to see more in our >>> Interop >>> > testing ( >>> > >>> http://files.opencompute.org/oc/public.php?service=files&t=60966a37f9643bc18074f52851d3dfca >>> > , slide 7) about having a common diagnostic monitoring utility for >>> NOSs to >>> > use since at present, most of them are only able to dump encoded pages >>> (see >>> > Test 2.3 from the Interop Test Plan rev 20: >>> > >>> http://www.opencompute.org/wiki/Networking/SpecsAndDesigns#Pluggable_Transceiver_and_Host_Compliance_and_Interopability_Test_Plan >>> > ). >>> >>> Sounds like a good idea to me. I know I've been wishing for such a tool >>> for a long time. >>> >>> > During this conversation, it was suggested that if such a tool were to >>> come >>> > to fruition by the group, that it would be a good idea to start with >>> > 'onlpdump' from ONLP, the platform abstraction interface from ONL ( >>> > >>> https://github.com/opennetworklinux/ONLP/tree/master/modules/onlp/module/src >>> > ). >>> >>> In addition to support for various Linux NOS distros I think we could >>> develop useful testing and verification features by processing SFF data >>> from files. So, I think a file backend and an ethtool API backend will >>> also make sense from the beginning. >>> >>> > What I would like to propose to the group is as follows: >>> > * gauge interest and interested parties willing to contribute (I'm >>> looking >>> > at NOS and pluggable vendors primarily but all is welcome) >>> > * establish goals and expectations >>> > * gather and review requirements for such a tool >>> > * determine if onlpdump is a suitable starting point >>> > * code >>> > * upstream >>> > * profit ;-) >>> >>> > As a quick high level stab of goals and expectations: >>> > * create a cross platform NOS utility (Linux only is fine as >>> practically >>> > all NOSs are Linux based) to provide proper utilization of the decoded >>> > diagnostic monitoring data in a (pluggable) vendor neutral fashion. >>> > Meaning, as long as we have the decoder ring for a given vendor, this >>> tool >>> > can make use of their pluggables. >>> > * all code is done in github, under an OCP Networking - in progress >>> repo >>> > * all code that is kernel specific, shall be up-streamed to the Linux >>> > kernel in a timely fashion for all to use and integrate >>> >>> Cool, the combination of having the decoder on github and the low-level >>> SFF interface access in the mainline Linux kernel is key. >>> >>> > Do we have any takers? >>> >>> I'd like to be involved, count me in :) >>> >>> --Dustin >>> _______________________________________________ >>> opencompute-networking mailing list >>> Unsubscribe: >>> http://lists.opencompute.org/mailman/options/opencompute-networking >>> >>> opencompute-networking@lists.opencompute.org >>> http://lists.opencompute.org/mailman/listinfo/opencompute-networking >>> >> >> >
_______________________________________________ opencompute-networking mailing list Unsubscribe: http://lists.opencompute.org/mailman/options/opencompute-networking opencompute-networking@lists.opencompute.org http://lists.opencompute.org/mailman/listinfo/opencompute-networking
