TECHNICAL FIELD

This disclosure relates to at least one mechanism to permit, at least in part, allocation and/or configuration, at least in part, of at least one network-associated object, e.g., by at least one process.

BACKGROUND

In one conventional distributed computing system, a switch fabric permits communication among the system's resources. Depending upon the particular application to which the system is intended to be put, the nature and/or characteristics of the fabric and resources may vary. For example, for high performance parallel computing applications, the fabric and resources may be configured so as to provide low latency, high bandwidth, and scalable communication between or among the system's resources and processes. Additionally, in prior conventional techniques, the system's intended usage model has dictated the specific types of programming models and interfaces to be employed. For example, systems that implement scientific coding-related usage models typically have employed the Message Passing Interface (MPI) programming model (e.g., of the type described in “MPI: A Message-Passing Interface Standard, Version 3.0,” Message Passing Interface Forum, Sep. 21, 2012) and related/conforming interfaces. Also, for example, conventional systems that operate on irregular data structures have employed the Partitioned Global Address Space (PGAS) programming languages model and related/conforming interfaces. Additionally, for example, conventional systems that process relatively large amounts of data have employed the Map Reduce programming model of Google Inc. of Mountain View, Calif., United States of America, and related/conforming interfaces. The respective underlying philosophies, semantics, and/or other specifics of these programming models and interfaces tend to be very different from each other.

Typically, in order to be able to provide sufficiently high performance, the interfaces are designed in such a way as to be very closely attuned to the specific fabric hardware that is employed in the system. This tends to increase the degree to which such interfaces differ from each other, depending upon the particular programming model and fabric hardware employed in the system.

As can be readily appreciated, as a result of the foregoing, in such conventional systems, hardware or software developed in accordance with a particular programming model, and/or for use with a specific interface and/or fabric hardware often cannot be easily redeployed for use, or interoperate with, other hardware or software developed in accordance with different programming models, and/or for use with other interfaces and/or fabric hardware. Additionally, in such conventional systems, it is often difficult to combine and/or utilize library functions, interfaces, etc. associated with a specific programming model and/or fabric hardware, with other library functions, interfaces, etc. associated with other programming models and/or fabric hardware. Furthermore, none of these conventional systems permit cohesive, robust interoperability of multiple different programming models, libraries, interfaces, and/or fabric hardware in a single system. Additionally, none of these conventional systems facilitate relatively easy extensibility of the programming models and/or interfaces employed (e.g., so as to be enhanced to support new, other, and/or additional features, capabilities, functions, etc.), while also permitting implementation of hardware-specific optimizations.

