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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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
