Hey Craig, If y'all got the ball, let's keep it moving!!!
Do you mind sharing the following: * docs, meeting minutes, etc... * code (if you have something) * how others can participate I'm sure others would like to get caught up with what y'all have so far to make meaningful contributions. On an administrative front, who's going to be the point person on this effort? Finisar (you), Accton, Broadcom, or some combination of the three? Just want someone (or a few someones) for when questions arise, I can direct them to the correct person. This is very exciting stuff Craig, I can't believe y'all were able to keep it on the DL for so long. ;-) +--+ Carlos On Thu, Oct 15, 2015 at 11:15 AM, Craig Thompson <craig.thomp...@finisar.com > wrote: > 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
