Today's guest post is by Reese Faucette, one of my fellow usNIC team members here at Cisco.

I'm pleased to announce that this past Friday, Cisco contributed a usNIC-based provider to libfabric, the new API in the works from OpenFabrics Interfaces Working Group.

(Editor's note: I've blogged about libfabric before)

Yes, the road is littered with the bodies of APIs that were great ideas at the time (or not), but that doesn't change the fact neither Berkeley sockets nor Linux Verbs are really adequate as cross-vendor, high-performance programming APIs.

The folks at OFIWG have, IMO, been doing a great job of soliciting input from and really listening to both app writers and hardware providers to develop an interface  which has broad appeal to both, without becoming so cumbersome and all-inclusive as to be unusable.

The API is still under development, sothere's still time to influence it with your own input!  Join the mailing list and join the weekly Tuesday Webex to join the fun!

Our usNIC provider currently supports unreliable datagrams (UD), which, as Jeff has mentioned before, are simply UDP packets - with no additional protocol layer.  This means libfabric-based programs using usNIC for UD messaging can seamlessly interoperate with sockets-based DGRAM programs (!).  It will also interoperate with the same binary running over a different provider, such as sockets, once those providers are developed.

Yes folks, you read that right:you can use usNIC UDP on one side of a connection, and regular kernel-based UDP on the other side.  Server-side acceleration, anyone?

How cool is that?
(Answer:very cool)

Note that in addition to datagrams, libfabric also defines semantics for various flavors of both reliable messaging and RDMA.  Stay tuned.

We're very excited about this -a lot of folks have been asking about how they can write programs directly to usNIC when MPI is not quite the right paradigm.  We now have a good answer for them without having to release a home-grown API or shoehorn into some API that's too closely tied to other hardware to really be efficient.

There are already four different providers for libfabric; we expect to see that number continue to grow even before version 1.0 is released.  Meaning: effort spent learning and porting apps to libfabric will be time well spent.

Viva libfabric!