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.
