Rob and Carlos – as some (not all) of you are aware, Finisar+Broadcom+Accton have been working on a code base for an ‘Open Optical Monitoring’ utility that aims to achieve much of what is being described below. ie a common set of drivers and APIs that can be used to access information and functions on pluggable modules through the NOS (focusing on Linux-based today). Some of this information and functionality is standard across vendors, largely defined by industry and MSA standards, and some of the information/functionality will be vendor-specific. The goal would be to define a framework that allows access to both types of information.
Since we have been quietly working on this over the past 6 months, and made some progress already, I’d like volunteer Finisar/Broadcom/Accton to lead the effort and gather input from the collective (NOS vendors, module vendors etc). Craig From: opencompute-networking-boun...@lists.opencompute.org [mailto:opencompute-networking-boun...@lists.opencompute.org] On Behalf Of Rob Sherwood Sent: Thursday, October 15, 2015 11:02 AM To: Carlos Cardenas Cc: opencompute-networking@lists.opencompute.org Subject: Re: [Opencompute-networking] Call for Interest on common DMI utility for pluggables Absolutely -- I think the work here is to get consensus that the sff and onlp libraries are a reasonable place to start and then try to work with the different vendors to understand their non-standard pages. By a show of emails, which DMI vendors would be interested in adding their decoding routines to a code base like this? Happy to try to marshall this activity. - Rob . On Thu, Oct 15, 2015 at 9:46 AM, Carlos Cardenas <car...@cumulusnetworks.com> wrote: 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
