Top 5 Reasons the HPC Community Should Care About libfabric

I’ve mentioned libfabric on this blog a few times: it’s a set of next-generation APIs that allow direct access to networking hardware (e.g., high-speed / low latency NICs) from Linux userspace (kernel access is in the works).

To give you a little perspective: the libfabric APIs are aimed at a lower layer than MPI.  libfabric seeks to unify and extend competing networking APIS – sockets, Linux Verbs, PSM, etc., to allow the production of extremely high performance code that is truly portable.

“…ummm, sure.  Why do I care?” you say.

I’m glad you asked!  Sean Hefty — one of the principal designers of libfabric — and I came up with this handy Top 5 list to tell you exactly why you care.

1. Libfabric has application-driven APIs.  Application use cases are the foundation on which libfabric APIs are designed.  Case in point: the libfabric APIs expose capabilities that MPI implementations have been asking for the past 10+ years.  Although MPI is one of the largest initial targets, writers of other classes of applications, both inside and outside the HPC community, are regularly invited to present their requirements and wishes to the libfabric working group.

2. Libfabric concentrates on performance and scalability.  The libfabric APIs are designed for modern networking hardware, particularly in terms of latency and scalability.  As we move towards the exascale era of computing, it will be critical to have a network API that is capable of communicating with hundreds of thousands — and even millions — of peers without consuming undue amounts of resources, while still maintain high levels of performance.  Libfabric was specifically designed to be able to meet these requirements.

3. Libfabric is designed for extensibility.  The core libfabric APIs are shaping up nicely, but there’s a long laundry list of other features we want to explore, including (but not limited to): more forms of MPI offload, storage, and PGAS support.  Additionally, explicit hooks are fundamentally designed in to libfabric that allow vendor-specific extensions to be exposed without compromising portability with the core libfabric APIs.

4. Libfabric is hardware independent.  The Linux Verbs API started its life as an API for InfiniBand hardware.  Although a few other hardware devices have been ported to the Linux Verbs API, they all struggle to match the IB abstractions to their own hardware (I speak from personal experience here).  Libfabric was deliberately designed to be independent of a specific hardware model, thereby making the API attractive to a wide set of network hardware vendors. Supporting this independence without conformance-induced performance penalties is of paramount importance and is what drives much of the discussion in the libfabric community.

5. Libfabric has a large, strong community.  Continuing the great tradition of open source in the HPC community, libfabric is being developed with an open, transparent process.  Anyone is invited to join the weekly Tuesday design Webex.  All the code is available on GitHub.  Input is actively sought from all corners of the HPC community.

Now is the time to get involved in libfabric.

Viva libfabric!

Share