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
