Yup, agree that this is a key enabler, and that this is a problem we’ve been talking about for a while. Looking forward to hear what you’ve been thinking about!
Glad to hear y’all will be working together – looking forward to the updates :) From: Craig Thompson <craig.thomp...@finisar.com<mailto:craig.thomp...@finisar.com>> Date: Thursday, October 15, 2015 at 3:25 PM To: Carlos Cardenas <car...@cumulusnetworks.com<mailto:car...@cumulusnetworks.com>> Cc: Omar Baldonado <o...@fb.com<mailto:o...@fb.com>>, "opencompute-networking@lists.opencompute.org<mailto:opencompute-networking@lists.opencompute.org>" <opencompute-networking@lists.opencompute.org<mailto:opencompute-networking@lists.opencompute.org>>, Pete Maricle <pete_mari...@accton.com<mailto:pete_mari...@accton.com>> Subject: Re: [Opencompute-networking] Call for Interest on common DMIutility for pluggables Omar - Carlos is right on. Someone can rush out code to solve a point problem, if it's useful to the community, but we've been trying to think about this at a higher level. To be fair, we brought this up at an OCP engineering meeting at UNH over a year ago. It wasn't even on anyone's radar or priority list until the past few weeks. So we didn't feel the urgency to contribute to you open community yet. We'll connect with Rob, Jeff and others ASAP and agree on what can be released immediately (and iterated), and what needs more thought and structure put into it. Craig On Oct 15, 2015, at 2:41 PM, Carlos Cardenas <car...@cumulusnetworks.com<mailto:car...@cumulusnetworks.com>> wrote: Omar, I think you are misconstruing the point. Having a utility to dump standards based EEPROM data is done (or should be in the case of ONL) according to SFF and MSA standards. That's not the issue. The issue is using the 'non-standard' pages in the EEPROM. A simple mmap or block read/write may be insufficient for some vendors capabilities, thus the progress (or lack there of in) is justified. Based on the doc Pete shared, it looks like they are well underway. For a common utility to use vendor's non-standard pages is not a show stopper for Interop testing, but a key enabler going forward. If a NOS can dump the standard pages for SFP and QSFP EEPROM, they are not going to pass the interop test. The purpose of the utility to allow users the ability to query and use all of a given vendor's part rather than the lowest common denominator (link establishment, link down, query basic EEPROM). +--+ Carlos On Thu, Oct 15, 2015 at 1:40 PM, Omar Baldonado <o...@fb.com<mailto:o...@fb.com>> wrote: Hi Craig, At first, I thought there was already working code + specs that you could contribute to the open given you¹d been working on it for 6 months, but it sounds like it is at basically a concept phase. Given that, can you also add OpenNetLinux folks (Rob/Jeff) to the list of parties to understand what they have so far as they already have experience with it and already have working code there? Also, not clear how much we need in addition to this in terms of a big framework/etcŠ my impression was that OCP testing efforts needs something asap, and hopefully that can happen sooner than later. If there is a need for a larger ³architecture² then let¹s present that to the community. Finally, hope we can iterate on this out in the open and let it take shape with the community - no need to bake a complete plan/architecture offlineŠ :) Hopefully you all can get together, figure out some high-level ideas and then iterate with everyone. Thanks! Omar On 10/15/15, 1:30 PM, "opencompute-networking-boun...@lists.opencompute.org<mailto:opencompute-networking-boun...@lists.opencompute.org> on behalf of Craig Thompson" <opencompute-networking-boun...@lists.opencompute.org<mailto:opencompute-networking-boun...@lists.opencompute.org> on behalf of craig.thomp...@finisar.com<mailto:craig.thomp...@finisar.com>> wrote: >I think Pete understates the effort that has been put into this so far. >Some code has been written and we're in the early stages of API >definition with Accton and Broadcom. The thought was to put more meat >around this before bringing it to OCP. However the level of interest has >accelerated our plans. > >The next step would be to bring all this together in a common spec. > >I suggest that the 3 parties (Finisar, Accton, Broadcom) come back to the >reflector with an initial proposal, scope of work and next steps. > >I'll take this offline for now and will be back shortly. > >Craig _______________________________________________ opencompute-networking mailing list Unsubscribe: http://lists.opencompute.org/mailman/options/opencompute-networking<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.opencompute.org_mailman_options_opencompute-2Dnetworking&d=BQMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=9OXeVvb4F_3KpIM1FO0Uig&m=uOMUZR0ul-0pu9Sq_lbem3JxIUN9FFQDmwgIHiXodWg&s=F1b0Yn2iSplQ98zYlN-pLQLpnSU_bXkNtE3-Ps70RkE&e=> opencompute-networking@lists.opencompute.org<mailto:opencompute-networking@lists.opencompute.org> http://lists.opencompute.org/mailman/listinfo/opencompute-networking<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.opencompute.org_mailman_listinfo_opencompute-2Dnetworking&d=BQMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=9OXeVvb4F_3KpIM1FO0Uig&m=uOMUZR0ul-0pu9Sq_lbem3JxIUN9FFQDmwgIHiXodWg&s=o_3hSBeuZrC6EgTSJh2GUe0RBgCFxmCkBTByVyMwtbU&e=>
_______________________________________________ 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
