This implementation is a user-level port on top of GM, the low-level communication interface for Myrinet, supported by Myricom. As the main resource used by VI-GM is memory, it supports a very large number of VI objects like Virtual Interfaces (VI), Completion Queues (CQ), etc. The current limits are defined in the include/vipl_config.h file and can be changed by customers, respecting the coding limit indicated for each value.
No configuration is required in VI-GM, only the VI-GM connection manager should be initially running when VI-GM applications are executed (if they need to establish connections, but as VI is connection-oriented, it's almost a requirement). Customers do not need to manage GM ports, VipOpenNic will try to open the first GM port available (starting from port 2).
VI-GM is completely thread-safe, and multiple VI-GM threads spawned from the same process share the same GM port. VI-GM does not use any signals and does not overload any function from the C library. VI-GM supports a very large number of nodes (65000+) and a virtually unlimited number of local threads (the number of NIC handles is limited to comply with the Intel conformance suite).
gm.h and be linked with libvipl.a, libgm.a and libpthread.a as in the following example: gcc -I/usr/local/gm/include -L/usr/local/gm/lib foo.c -o foo -lvipl -lgm -lpthread
A VI-GM device name is formed by the prefix VINIC followed by the Myrinet interface index, or nothing to specify the first interface :
VINIC represents the first Myrinet interface in the machine.VINIC0 represents the first Myrinet interface in the machine.VINIC1 represents the second Myrinet interface in the machine.VINIC2 represents the third Myrinet interface in the machine.
The host part of a VI-GM net address is identical to the interface MAC address, known as lanai_board_id by gm_board_info. This MAC address is composed of 6 Bytes and always starts with 00:60:dd:7f (Myricom prefix). The name service is fully operational and uses the routing table set by the GM mapper. 
1.4.4.