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> > 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> 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 on behalf of Craig >> Thompson" <opencompute-networking-boun...@lists.opencompute.org on behalf >> of 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 >> >> 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
