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
