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
