(thanks JeffT for the quick patch:
https://github.com/opennetworklinux/ONLP/commit/e151905883d5b0f50b5eca67aad4279850948bfe
)
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
> and
> https://github.com/opennetworklinux/ONLP/blob/master/modules/sff/module/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=60966a37f9643bc18074f52851d3dfca
>> > , 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
>> > ).
>>
>> 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
>> > ).
>>
>> 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
>>
>
>
_______________________________________________
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
