Hey Greg, You're absolutely right, NOS/box vendors have been "abusing" the EEPROM for quite some time to create "value add" *cough* lock-in *cough* ;-)
If you think it's a good idea, we can implement a "whistle blower immunity" policy where vendors can "blow the whistle" when others attempt to "innovate" in this space to exert control. We can even have a public flogging. ;-) Joking, of course....but not really. +--+ Carlos On Thu, Oct 15, 2015 at 11:04 AM, Greg McSorley < greg.mcsor...@amphenol-highspeed.com> wrote: > Hi Carlos, > > One thing to keep in mind here is that, it is not always the module and or > / DAC vendors that are putting that “extra” info in the module. Many times > that information is requested and demanded by the individual server / box > vendors. > > The decoder ring that you speak is more often than not, controlled by the > box vendor, who only wants certain module / DAC’s plugged in to their > systems. > > Just something to keep in mind while we are doing this work. > > Thanks > > Greg > > > > > > > > > > Greg McSorley > > Amphenol High Speed Products > > Cell: 508-561-2903 > > Email: greg.mcsor...@amphenol-highspeed.com > > > > *From:* opencompute-networking-boun...@lists.opencompute.org [mailto: > opencompute-networking-boun...@lists.opencompute.org] *On Behalf Of *Carlos > Cardenas > *Sent:* Thursday, October 15, 2015 12:46 PM > *To:* Rob Sherwood > *Cc:* opencompute-networking@lists.opencompute.org > *Subject:* Re: [Opencompute-networking] Call for Interest on common DMI > utility for pluggables > > > > 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 > <http://cp.mcafee.com/d/avndz8O86Qm663hOCessodTdETsKYCed7dS3qdTbL9zzhOYqejqdTbL9zzhPtYSztNxUsOOPsShzV7BrkH4_OMa21fUlfbAV4it5LZ3BPog9_2FVsD8yjEJ_EsKrKgugthsvW_8TKUehd7fnKnjpohV5UsepopWyaqRQRrTjVkffGhBrwqrhdETdTVd4QsLnsvjhsdTdw0GHv1tpKvY01MN8Hb0pYP5oBpg8Ucbvqwx10e-Ayca0o5zSO97i1_yE9zIam-hDUyKMg5gLmANkiGGIvbomYlS20G6MDYqHqgAvapol1fQCaxo_o6WHv1tpKvBMqoH4Ha14KgGT2TQ1hYGjFRlLwKITf-00CQNP38US2_id41Fr32TMnmrDVs6CaNaOwhdbFEw4Jffd43JoCy0dxfU_ipEwH0QgbGRwq80Ur3jh0TehYFBzh0Xm9Ewmfr8At87_gSYOrCYPc19F> > 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 > <http://cp.mcafee.com/d/avndxMO73hJ5xxwQsFzD763tPqdTbL9zzhPtwSztOXOoUQsL6zASztOXOoUQsTvdETsou7cIITdAo-hVmRaNfYI2wwj-5jOVeh4Dhr_gVsS42vMGun9O8AWbvW7bCXA7A7kn7-LOdXK3AjhPRXBQSm4uhu73Cm6uEyCJtdmZQ-l3PWApmU6CQPqdPt-jhd7bRT7QQn3tPpesRG9px6kOrp3BYGJY0qoH4Gva3ovwo1wl2SbGODDELECzCXXPPa3V2XHZO3_SRMtKEc9zzhOY_sQsIf47vdRm-2WPs_bwQNm9mk29sxlK5LE2zVkDjGHv1tpKvY01dFzC6hNI5-Aq83iS65LwKITfOUdclylB0yqnjh09quuq87qNd40r2vN-APh1m1EwnlH0Qg1MS6Cy1KszVjb6y1SIjh0IuSh8Wgf-xJVASKn9> > ) > > > > 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 > <http://cp.mcafee.com/d/2DRPoQ939J5xxwQsFzD763tPqdTbL9zzhPtwSztOXOoUQsL6zASztOXOoUQsTvdETsou7cIITdAo-hVmRaNfYI2wwj-5jOVeh4Dhr_gVsS42vMGun9O8AWbvW7bCXA7A7kn7-LOdXK3AjhPRXBQSm4uhu73Cm6uEyCJtdmZQ-l3PWApmU6CSjqdPt-jhd7bRT7QQn3tPpesRG9px6kOrp3BYGJY0qoH4Gva3ovwo1wl2Sjz_UHJ9_75qEdD_jaeKUHl1I_YF6NKGTMnmrDVs6CaNaOwhbAaJMJZ0kvaAWtlrUbHdP_w09JcsMOedwLQzh0qmMMJY5RCV-n1FyIiIE4jiWq81bjPPh0Xm9Ew3oj-fQCq8aMd42WJo6y0e6MQQgdPAvapoQgeRyq85zSO97i1_QdLcCQT97> > and > https://github.com/opennetworklinux/ONLP/blob/master/modules/sff/module/inc/sff/sff.h#L245 > <http://cp.mcafee.com/d/2DRPoQ96Qm663hOCessodTdETsKYCed7dS3qdTbL9zzhOYqejqdTbL9zzhPtYSztNxUsOOPsShzV7BrkH4_OMa21fUlfbAV4it5LZ3BPog9_2FVsD8yjEJ_EsKrKgugthsvW_8TKUehd7fnKnjpohV5UsepopWyaqRQRrTjVkffGhBrwqrodETdTVd4QsLnsvjhsdTdAVPmEBC4pj9JAenOGTM1FyIiFYEdx-1w61kbogfGgNnqj-eaRgrf-CkttNmG3p_Va5IEWXB7nu9wo5kS7PtlLwKITfOUdclylB0yn8lrxrW0E-l9QWGTMnmrD_00jqoVxAsr1vF6y0QJxxrUbHdPYK3j5oBpg8CBQQg2mDDCy1SIjh06MDYvFcQglwq85RqMd40sdxFEwrD8-kONEwtH4Qgb7JAieA3_Erupdx4zhYMEb>), > 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 > <http://cp.mcafee.com/d/1jWVIe6hESyMMMqekNPzz1KVJ6XBTANNEVKMrhKVtVcsqenzhOrhKVtVcsqerLCQrKcf3CmmrCOcv8YHqBoD-m1gg9_2FVsD8yjEJ_EsKr21fUlfbAV4it5LZ3BPtO3O3Gbz_nV6ZT1O9EVWZOWrb2f8L3xPb3fkhjmKCHuWvaxVZicHs3jrVJ6VK_9ECzBWXzWqbxKVI05lrUbHdP_w0e695po3fCoH4Ha1705H4HgDloKDt5YLsQsCWHv1tpKvBMqoH4Ha14KgGT2TQ1hYGjFRlLwKITf-00CQNP38US2_id41Fr32TMnmrDVs6CaNaOwhdbFEw4Jffd43JoCy0dxfU_ipEwH0QgbGRwq80Ur3jh0TehYFBzh0Xm9Ewmfr8At87_gSYOrcdoU> > ), > > 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 > <http://cp.mcafee.com/d/2DRPoA820sd6Qm663hOCessodTdETsKYCed7dS3qdTbL9zzhOYqejqdTbL9zzhPtYSztNxUsOOPsShzV7BrkH4_OMa21fUlfbAV4it5LZ3BPog9_2FVsD8yjEJ_EsKrKgugthsvW_8TKUehd7fnKnjpohV5UsepopWyaqRQRrTjVkffGhBrwqrsdETdTVd4QsLnsvjhsdTdw0Tp7_jGHv1tpKvY01OJImr87OJMh9k-9ClLetAvZ6ww29Dend7bzCIzDjhOUMOgIyZssMW-CY-ywOwXrjtlLwKITfOUdclylB0yn8lrxrW0E-l9QWGTMnmrD_00jqoVxAsr1vF6y0QJxxrUbHdPYK3j5oBpg8CBQQg2mDDCy1SIjh06MDYvFcQglwq85RqMd40sdxFEwrD8-kONEwtH4Qgb7JAieA3_ErupdzX1_4KWANgv> > > , 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 > <http://cp.mcafee.com/d/k-Kr41AedEIcc6zBcsUUMrKrhKVtVcsqerI6QrKnuj76zBUQsCQrKnuj76zCXVJ6Xz3MVBBCVIz7OfaSFm9_Bwk42vMGun9O8AWbvW7bCMwj-5jOVeh4Dhr_gVsTswYwWyU_R-hLtMsyqeuLsKCOMzObMUsOMPR4kRHFGTKDOEuvkzaT0QSedETdTVd4QsLnsvjhsdTdw0GHv1tpKvY01MN8Hb0pYP5oBpg8Ucbvqwx10e-Ayca0o5zSO97i1_yE9zIam-hDUyKMg5gLmANkiGGIvbomYlS20G6MDYqHqgAvapol1fQCaxo_o6WHv1tpKvBMqoH4Ha14KgGT2TQ1hYGjFRlLwKITf-00CQNP38US2_id41Fr32TMnmrDVs6CaNaOwhdbFEw4Jffd43JoCy0dxfU_ipEwH0QgbGRwq80Ur3jh0TehYFBzh0Xm9Ewmfr8At87_gSYOraYqU> > > ). > > 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 > <http://cp.mcafee.com/d/avndz8Q93hJ5xxwQsFzD763tPqdTbL9zzhPtwSztOXOoUQsL6zASztOXOoUQsTvdETsou7cIITdAo-hVmRaNfYI2wwj-5jOVeh4Dhr_gVsS42vMGun9O8AWbvW7bCXA7A7kn7-LOdXK3AjhPRXBQSm4uhu73Cm6uEyCJtdmZQ-l3PWApmU6CTzqdPt-jhd7bRT7QQn3tPpesRG9px6kOrp3BYGJY0qoH4Gva3ovwo1wl2Sjz_UHJ9_75qEdD_jaMfmNmG3p_VidztlLwKITfOUdclylB0yn8lrxrW0E-l9QWGTMnmrD_00jqoVxAsr1vF6y0QJxxrUbHdPYK3j5oBpg8CBQQg2mDDCy1SIjh06MDYvFcQglwq85RqMd40sdxFEwrD8-kONEwtH4Qgb7JAieA3_Erupd-vsI> > > ). > > 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 > <http://cp.mcafee.com/d/5fHCNEedEIcc6zBcsUUMrKrhKVtVcsqerI6QrKnuj76zBUQsCQrKnuj76zCXVJ6Xz3MVBBCVIz7OfaSFm9_Bwk42vMGun9O8AWbvW7bCMwj-5jOVeh4Dhr_gVsTswYwWyU_R-hLtMsyqeuLsKCOMzObMUsOMPR4kRHFGTKDOEuvkzaT0QSqejqdPt-jhd7bRT7QQn3tPo0c-l9QWGTMnmrD_00s4RtxBlFOH2Clm-2WPs_bwQNm9mk29KGTMnmrDVs6CaNaOwhbAaJMJZ0kvaAWtlrUbHdP_w09JcsMOedwLQzh0qmMMJY5RCV-n1FyIiIE4jiWq81bjPPh0Xm9Ew3oj-fQCq8aMd42WJo6y0e6MQQgdPAvapoQgeRyq85zSO97i1_QdLcCXLRJuTh9tgso> > > opencompute-networking@lists.opencompute.org > http://lists.opencompute.org/mailman/listinfo/opencompute-networking > <http://cp.mcafee.com/d/FZsSd20OcCQm663hOCessodTdETsKYCed7dS3qdTbL9zzhOYqejqdTbL9zzhPtYSztNxUsOOPsShzV7BrkH4_OMa21fUlfbAV4it5LZ3BPog9_2FVsD8yjEJ_EsKrKgugthsvW_8TKUehd7fnKnjpohV5UsepopWyaqRQRrTjVkffGhBrwqrhKrhKrLOq9EVuKU-CyUrKr01DOFeDlm-2WPs_U03wCHIcfBisEeROGTMnmrDVs6CaNaOwhdRm-2WPs_bwQNm9mk29sxlK5LE2zVkDjGHv1tpKvY01dFzC6hNI5-Aq83iS65LwKITfOUdclylB0yqnjh09quuq87qNd40r2vN-APh1m1EwnlH0Qg1MS6Cy1KszVjb6y1SIjh0IuSh8Wgf-xJVASMGAe1tt8-N1> > > > > > > >
_______________________________________________ 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
