Compliance and Interoperability
Discussion
11/25/2014
Paul Grun
C&I
• Already agreed on several criteria leading up to
a release:
– Provider existence proof, test cases, man pages…
• Should we also include either compliance or
interoperability testing
– Either as part of the release process or as an adjunct
to it
• Should the OFA provide a C&I service for
libfabrics implementations?
ISC 2013
2
Compliance
• Compliance: An implementation is said to be
compliant with a set of requirements if it
conforms to those requirements through some
measurable objective criteria
• Important point: “Compliance of what, with
respect to what?”
• Typically, requirements are stated in formal
language as part of a specification
– There is no formal libfabrics specification
ISC 2013
3
In terms of classical layering…
protocol
Application
Application
consumer
consumer
interface
provider
provider
hardware
hardware
- Any given layer has a vertical interface to the layers above it and
below it.
- Peer layers communicate with each other via a protocol.
Compliance, Interoperability
Application
Application
consumer
consumer
provider
provider
hardware
hardware
Technically:
Interoperability describes how accurately two peers exchange a well-defined protocol.
Compliance describes how well a given layer conforms to an interface specification.
Compliance, Interoperability
Application
Application
interop
consumer
consumer
compliance
provider
provider
hardware
hardware
For our purposes, roughly:
Interoperability is the horizontal relationship between peer layers,
Compliance is the vertical relationship between adjacent layers.
Application layer
Application
Application
consumer
consumer
provider
provider
hardware
hardware
Interoperability among instances of an application is defined solely by
the...application.
Similarly, the interface to the consumer is defined by a combination of
the consumer and the application.
Both are outside the scope of the OFA.
Consumer layer
Application
Application
consumer
consumer
provider
provider
hardware
hardware
The consumer protocol is defined by…somebody else (OpenMPI,
MPICH…). Outside the scope of the OFA.
But the consumer/provider interface is defined by us (OFI WG). Very
much in scope for the OFA.
Should the OFA define a compliance test for OFI WG consumers?
Provider layer
Application
Application
consumer
consumer
provider
provider
hardware
hardware
As above, the consumer/provider interface is defined by OFI WG.
Should the OFA define a compliance test for OFI providers? Not clear!
What about the end-to-end provider protocol? Again, not clear.
Hardware layer
Application
Application
consumer
consumer
provider
provider
hardware
hardware
Interoperability on the wire is defined by an industry standard –
ENET, FCOE, IB…Clearly out of scope for the OFA.
Likewise, the provider/hardware interface is the province of
somebody else.
Example: MPI
Application
defined by MPI
Application
MPI
MPI
OFI provider
OFI provider
hardware
hardware
The MPI on-the-wire protocol is defined by somebody like OpenMPI, MPICH, etc…
The application interface is similarly defined by somebody else.
In both cases, this is outside the scope of the OFA
Example: MPI
Application
defined by MPI
MPI
Application
MPI
libfabrics API
OFI provider
hardware
defined by OFA
OFI provider
hardware
But the interface to the OFI provider is defined by the OFA – OFI
Example: MPI
Application
MPI
Application
1
2
MPI
libfabrics API
OFI provider
OFI provider
hardware
hardware
As an industry service, the OFA could provide:
1. Compliance testing of the MPI implementation to the OFI-defined APIs
• but not the MPI on-the-wire protocol
2. Compliance testing of the provider implementation to the OFI-defined APIs
Example: MPI
Application
Application
MPI
1
OFI provider
hardware
2
MPI
libfabrics API
OFI provider
3
hardware
As an industry service, the OFA could provide:
1. Compliance testing of the MPI implementation to the OFI-defined APIs
• but not the MPI on-the-wire protocol
2. Compliance testing of the provider implementation to the OFI-defined APIs
3. Protocol testing of provider layer on-the-wire protocols
Discussion
ISC 2013