netdev - Re: [E1000-devel] ixgbe: Unsupported SFP+ modules on 10Gbit/s X520-DA2 NIC?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Jan 2012 12:50:54 +0100
From:	David Lamparter <equinox@...c24.net>
To:	Ben Greear <greearb@...delatech.com>
Cc:	"Fujinaka, Todd" <todd.fujinaka@...el.com>,
	Benny Amorsen <benny+usenet@...rsen.dk>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	Jesper Dangaard Brouer <hawk@...x.dk>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [E1000-devel] ixgbe: Unsupported SFP+ modules on 10Gbit/s
 X520-DA2 NIC?

On Wed, Jan 18, 2012 at 02:40:47PM -0800, Ben Greear wrote:
> On 01/18/2012 02:21 PM, Fujinaka, Todd wrote:
> > Jesse Brandeburg<jesse.brandeburg@...el.com>  writes:
> >
> >> For X520 adapters, the documentation[1] states that which SFP+
> >> adapters are/are not supported.  Direct attach cables are also
> >> supported.
> >>
> >> [1]
> >> http://www.intel.com/support/network/adapter/pro100/sb/CS-030612.htm
> >
> > I can't believe that locked optics have now arrived on commodity hardware. I have been trying to migrate to all-Intel networking at work; that effort is certainly on hold now.
> >
> >
> > That's up to you. There's "locked" and there's "locked". I'm surprised
> > that Benny and Jesper haven't looked at the driver to see where the
> > messages come from.
> 
> As a datapoint:  We had a customer trying to use a non-supported
> SFP+ module in an 82599 NIC, and they hacked the driver to over-rule
> the exclusion.  It sort of worked for them, but never well, and never
> at any decent throughput.
> 
> Now, I have no idea if their SFP+ was decent or not, but at least in
> some cases, just over-riding the driver doesn't fix things.
> 
> It does seem like Intel could offer a module option to easily over-ride the
> SFP+ exclusion for folks that wanted to test new SFP+ modules for them,
> however.

Sorry, but the whole practice is complete and utter bullshit. And I'm
saying that as a hardware engineer.

For starters, there are only a handful manufacturers that actually make
SFPs. I don't have numbers but I'd claim Finisar, Avago and JDSU have
at least 50% of the market. (cf.
http://www.finisar.com/faq/Operational-Information:
"Who are some of the competitors in these businesses?
"Finisar competes primarily with Avago, CoAdna, JDSU, Oclaro, Opnext,
Oplink, and Sumitomo.")

(By the way, on 1G SFPs the original price is around $20, from where the
OEM sticker gets them up to $150 in bad cases [Cisco]. No idea how bad
it is with 10G.)

Also, the electrical parameters are not that hard to quantify and test.
The spec has minimum eye opening requirements, maximum jitter allowance,
etc. - if a vendor gets them wrong, they'll fail quite quickly.

Further, look at Flexoptix and their "reflash the SFP" business model.
(http://www.flexoptix.net/)

Oh and you even get the same OEM sticker on different real vendors.

Intel isn't making their own SFPs, and they're not getting SFPs with
custom tweaks on the electrical interface from SFP vendors.

You can always get a shitty transceiver if the vendor has a bad day, but
that's not gonna be bound to the OEM sticker.

(btw, bad SFPs manifest as CRC/FCS errors, not as bad throughput. If you
have bad throughput but no errors, the NIC's firmware is fucking with
you.)

-David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html