Up and Down the Network Stack

Surf Your Lake

Swimming in Lake Michigan is actually quite nice (although not at this time of the year). However the evil life guards who terrorise peaceful swimmers are not. I've had stand up arguments ... quite literally since at the time I was getting ordered back to the shore, the water wasnt yet waist deep!

So I've got a lot of sympathy for RexFloodstrom who was arrested for surfing.

http://chicago.cbslocal.com/2012/02/16/surfer-arrested-at-oak-street-beach-gets-community-service/

 

 

Wow, what's that lurking under the new heatsink

 

This is the awesome new 6x22 NIC. Looks the business. Doubles the internal packet processing performance of the 5x22 NICs - you'll really see the effects on SandyBridge architecture machines. Significantly lower latency at all packet rates . Will sink line rate min packet size sustained to user-space with OpenOnload and sustains at 18Mpps with both ports active and running multiple streams. 

 

 

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.