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 > On Oct 15, 2015, at 12:33 PM, Pete Maricle <pete_mari...@accton.com> wrote: > > Hi Carlos, > > While we've been thinking about this for 6 months, as Craig said, we've been > so busy we haven't actually done that much work. We've only just started to > do anything with code. > > Our concept was to create a standard set of files in the sysfs that any > application could use to query/control the SFFs. This way the interface is > NOS agnostic as long as it's Linux based. It's also an easy interface to use > whether you are using Python, C, standard scripting, ... > > I've attached a file that briefly describes our initial thinking. It's not > complete so beware. > > - Pete > > -----Original Message----- > From: opencompute-networking-boun...@lists.opencompute.org > [mailto:opencompute-networking-boun...@lists.opencompute.org] On Behalf Of > opencompute-networking-requ...@lists.opencompute.org > Sent: Thursday, October 15, 2015 2:49 PM > To: opencompute-networking@lists.opencompute.org > Subject: opencompute-networking Digest, Vol 29, Issue 10 > > Send opencompute-networking mailing list submissions to > opencompute-networking@lists.opencompute.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.opencompute.org/mailman/listinfo/opencompute-networking > or, via email, send a message with subject or body 'help' to > opencompute-networking-requ...@lists.opencompute.org > > You can reach the person managing the list at > opencompute-networking-ow...@lists.opencompute.org > > When replying, please edit your Subject line so it is more specific than "Re: > Contents of opencompute-networking digest..." > > > Today's Topics: > > 1. Re: Call for Interest on common DMI utility for pluggables > (Carlos Cardenas) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 15 Oct 2015 11:48:23 -0700 > From: Carlos Cardenas <car...@cumulusnetworks.com> > To: Craig Thompson <craig.thomp...@finisar.com> > Cc: "opencompute-networking@lists.opencompute.org" > <opencompute-networking@lists.opencompute.org> > Subject: Re: [Opencompute-networking] Call for Interest on common DMI > utility for pluggables > Message-ID: > <CAMgwifx_dAELcb=vueuO28GUvcZO5QVRAoExwWL=13tssyy...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hey Craig, > > If y'all got the ball, let's keep it moving!!! > > Do you mind sharing the following: > * docs, meeting minutes, etc... > * code (if you have something) > * how others can participate > > I'm sure others would like to get caught up with what y'all have so far to > make meaningful contributions. > > On an administrative front, who's going to be the point person on this > effort? Finisar (you), Accton, Broadcom, or some combination of the three? > Just want someone (or a few someones) for when questions arise, I can direct > them to the correct person. > > This is very exciting stuff Craig, I can't believe y'all were able to keep it > on the DL for so long. ;-) > > +--+ > Carlos > > On Thu, Oct 15, 2015 at 11:15 AM, Craig Thompson <craig.thomp...@finisar.com >> wrote: > >> Rob and Carlos ? as some (not all) of you are aware, >> Finisar+Broadcom+Accton have been working on a code base for an ?Open >> Optical Monitoring? utility that aims to achieve much of what is being >> described below. ie a common set of drivers and APIs that can be used >> to access information and functions on pluggable modules through the >> NOS (focusing on Linux-based today). Some of this information and >> functionality is standard across vendors, largely defined by industry >> and MSA standards, and some of the information/functionality will be >> vendor-specific. The goal would be to define a framework that allows >> access to both types of information. >> >> >> >> Since we have been quietly working on this over the past 6 months, and >> made some progress already, I?d like volunteer Finisar/Broadcom/Accton >> to lead the effort and gather input from the collective (NOS vendors, >> module vendors etc). >> >> >> >> Craig >> >> >> >> *From:* opencompute-networking-boun...@lists.opencompute.org [mailto: >> opencompute-networking-boun...@lists.opencompute.org] *On Behalf Of >> *Rob Sherwood >> *Sent:* Thursday, October 15, 2015 11:02 AM >> *To:* Carlos Cardenas >> *Cc:* opencompute-networking@lists.opencompute.org >> *Subject:* Re: [Opencompute-networking] Call for Interest on common >> DMI utility for pluggables >> >> >> >> 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_T >> ransceiver_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/e151905883d5b0f50b5eca >> 67aad4279850948bfe >> ) >> >> >> >> 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/modul >> e/src >> and >> https://github.com/opennetworklinux/ONLP/blob/master/modules/sff/modul >> e/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=60966a37f96 >> 43bc18074f52851d3dfca >>> , 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_T >> ransceiver_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/modu >> le/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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.opencompute.org/pipermail/opencompute-networking/attachments/20151015/43abc80b/attachment.html> > > ------------------------------ > > _______________________________________________ > opencompute-networking mailing list > opencompute-networking@lists.opencompute.org > http://lists.opencompute.org/mailman/listinfo/opencompute-networking > > > End of opencompute-networking Digest, Vol 29, Issue 10 > ****************************************************** > <Open Optical Interface.pdf> > _______________________________________________ > 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
