Re: [E1000-devel] i40e: source for nvmupdate64e? (to clear module qualification)

[Fujinaka, T. <tod...@in...>]

Unfortunately the source code for nvmupdate is not available at this time.

We do offer an open optics SKU of the adapter in question, and you may be able to order that instead of having to go poking around the NVM. Please contact your vendor regarding availability.

Also, I've been involved in several issues involving the "SFP+ standard" and it's not followed as closely as anyone would like. I would recommend avoiding low-priced DA cables, for example. There are also "vendor defined" options that immediately make something unique and non-standard even though the part physically fits in the cage. I'm not the guy making the decisions about this, I'm just the guy who gets to answer some of the questions.

Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
tod...@in...
(503) 712-4565

-----Original Message-----
From: Wesley W. Terpstra [mailto:we...@te...] 
Sent: Monday, March 21, 2016 3:11 AM
To: e10...@li...
Subject: Re: [E1000-devel] i40e: source for nvmupdate64e? (to clear module qualification)

Thank you for your feedback,

> Also be aware that a large chunk of the NVM image is signed and won't 
> work  if the signature and/or checksum is found invalid.  I don't 
> remember if the Qualified Module bits are in the signed portion, but I suspect they are.

The data sheet (Section 6) says that they are not.
Table 6-2 lists "EMP SR Settings" as Auth=No.

Furthermore, there is good reason to believe they *cannot* be signed.
The fields listed in Section 6.3.23 all say "Note: This field is preserved by the Intel NVM update tool." Therefore, either the update tool would need the private key to sign whatever it finds (rendering the exercise in security futile), or it would need to have a signed version for all combinations of these fields, or those fields are unsigned (by far the most likely).

So, I just need to find the fields, update them, and not break the CRC. The data sheet lists the CRC8 polynomial used, so that's not a problem.

I am still interested in finding a more up-to-date data sheet, the source code to nvmupdate64e, and/or more documentation regarding how the module pointers interact with the module index used in the i40e driver.

> Keep in mind that the qualified module table is to help us know that 
> the device will actually work with the optics being used.  We've had 
> to debug some strange things that came down to mis-behaving connectors.

Drifting off topic now, but here we go:

As a developer, I feel your pain.
Users are the worst.
Anything to head off lengthy support.

As a network admin, I wonder why you aren't validating the fibre optic cables, as I have had more problems with bad fibre, especially when installed by people who are more familiar with copper. At my day job, we tested several SFPs from four reputable manufacturers at various temperatures and with different rad-hard cables. In the end, all of the SFPs, from the most expensive to the quite inexpensive, worked equally well. The quality of the fibre mattered far more.

As a consumer, I am frustrated that a card I bought to support the
SFP+ standard instead only supports 10GBASE-LR or 10GBASE-T or
whatever else Intel is willing to sell me. The whole point of a standard is that I can use any component that conforms to the standard. There are plenty of very qualified manufacturers of optical transceivers. Most of them are not Intel.

Furthermore, while motherboard vendors list qualified RAM modules, they don't fail to boot if you install an unqualified module. They don't even give a warning! If the combination of RAM/SFP and motherboard/card do not work, that's my fault for not sticking to the qualified module list. Fine. The only thing a module white-list achieves is to guarantee that most combinations of SFP/card will fail to work. Meanwhile, my lab experience has shown that in reality, most combinations DO work.

At my day job, we also build (FPGA-based) optical network cards used as timing receivers. These boards store an SFP database in an EEPROM.
We need that database to quantify the delay in picoseconds through the PHY. If someone inserts a PHY we didn't list, we don't reject the module. We issue a warning and take a default delay value, resulting in a slightly desynchronized (but still syntonized) clock. IMNSHO, this is the only correct way to deal with the situation.

> I suggest you get in contact with your dealer or Intel Networking 
> support and see if they can help you out with your specific optics.

I bought the Intel X710-DA4 in question second-hand, for private use.
I already own a collection of SFPs. I *will* get the X710 to accept them by poking its NVM. It just might take me a few more weekends than I'd expected. Any help/documentation is appreciated.

Thanks!

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
E1000-devel mailing list
E10...@li...
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired