Up and Down the Network Stack

IXGBE broken with Non-OEM Optics ?

Watch this thread in progress:

http://thread.gmane.org/gmane.linux.network/218069

It  apears that Intel is locking SFP+ modules

http://www.intel.com/support/network/adapter/pro100/sb/CS-030612.htm

Jury is still out on whether this is just bullshit forcing customers to buy OEM branded optics, or whether there is a real hardware issue with the NIC.

There is a driver patch to disable the lockout,

+				adapter = hw->back; /* used by e_dev_err macro*/
+				e_dev_err(
+					"SFP+ module not supported by Intel\n");
+				if (allow_any_sfp) { /* modul param override */
+					e_dev_err(
+					"Continue WITHOUT support, SFP+ module "
+					"vendor OUI:0x%06X (enum phy.type:%d)\n",
+					vendor_oui >> 8, hw->phy.type);
+					status = 0;
+				} else {
+					hw->phy.type = ixgbe_phy_sfp_unsupported;
+					status = IXGBE_ERR_SFP_NOT_SUPPORTED;

but it's use at your own risk ...

Really!

 

 

 

Shoddy Onload Imitation Launched

I pointed out some of the architectural work we did with OpenOnload in this post and warned against shoddy imitations which offer cute microbenchmarks, but are not ready for serious production deployments.

And in case you were wondering about the alternatives, let me point you at a  light-weight TCP stack out there called lwIP - we use it internally and it's useful for simple embedded projects. Absolutely not designed for inclusion in a high-performance user-mode stack.

So I asked Kieran Mansley, the maintainer of lwIP whether he'd recommend it for use in a high-performance user-space protocol stack. He started laughing. In fact he was still spluttering an hour later, but did manage the following points of concern:

• Any sort of fully-featured control plane.  Things like how well it handles traffic when while it's waiting for an ARP response are pretty primitive.

•  Scalability.  It does lots of linear searching of lists (e.g. when it receives a packet and is looking for the connection to deliver it to)

•  It's pretty old-school in its choice of standards, so things like its congestion control algorithm are unlikely to be based on the more modern alternatives and its performance will suffer as a result.  "I don't think it does TCP window scaling, SACK, etc."

• Multi-threading.  lwIP is written with the assumption that only a single thread will be active in the stack at any one time.

• Reliability/conformance.  "It is free software developed as a hobby on the back of the goodwill of a small set of developers.  The resources available to test it are therefore far more limited than we would like, and close to zero."

 Hmmm ... I do hope that shoddy-immatator-Inc has improved its software QA process since the last 
time they tried to release TCP and also that they've significantly enhanced the architecture
and feature set of lwIP. (because yes, that's what I've heard is inside V**6) 

Erm..  otherwise they've released something more suitable for use in a boot-rom. 

The message remains the same, when faced with Mr Shoddy Imitator, just ask what it takes to:

-cope with applications which exit or otherwise become unresponsive

- achieve high-performance and full  transparency when using random sets of file descriptors on mixed accelerated / non-accelerated interfaces

- support fun at the POSIX API:  fork()/exec(), signals, SCM_RIGHTS and friends

- accelerate VLANs, teaming/failover

- deliver full RFC compliance. Including the good stuff .

Please tell them to stop wasting their time and money peddling shoddy imitations. If they want to do this right and had the balls, they would come  form an industry consortium around OpenOnload.