fi_sockets(7)

πŸ’– fi_sockets β€” the Sockets Fabric Provider πŸ’–

okay bestie, welcome to the fi_sockets page from the Libfabric manual (v2.5.1, iconic behavior). this is the group-chat rundown, but every single deet is still in here, promise 🫢


✨ NAME ✨

fi_sockets β€” literally the Sockets Fabric Provider, that's the whole vibe πŸ’…


🌸 OVERVIEW 🌸

So first things first, and I need you to sit down for this one: the sockets provider is being deprecated in favor of the tcp, udp, and utility providers 😭 further work on the sockets provider will be minimal. Most applications should use the tcp provider instead. periodt.

That said, here's what it is: the sockets provider is a general purpose provider that works on any system that supports TCP sockets πŸ¦‹ it's not out here trying to be faster than regular TCP sockets, no cap β€” its whole thing is letting developers write, test, and debug application code even on platforms that don't have high-performance fabric hardware. and yes, the sockets provider supports all libfabric provider requirements and interfaces. ate. πŸ‘‘


πŸŽ€ SUPPORTED FEATURES πŸŽ€

The sockets provider supports all the features defined for the libfabric API. Key features include:

⭐ Endpoint types

The provider supports all endpoint types, all of them, no skips: FI_EP_MSG, FI_EP_RDM, and FI_EP_DGRAM. slay πŸ’œ

⭐ Endpoint capabilities

The following data transfer interface is supported for a all endpoint types: fi_msg. (yes, the original says "a all", we're keeping it, it's part of the lore πŸ™ˆ)

Additionally, these interfaces are supported for reliable endpoints (FI_EP_MSG and FI_EP_RDM): fi_tagged, fi_atomic, and fi_rma πŸ”₯

⭐ Modes

The sockets provider supports all operational modes including FI_CONTEXT and FI_MSG_PREFIX. ✨

⭐ Progress

Sockets provider supports both FI_PROGRESS_AUTO and FI_PROGRESS_MANUAL, with a default set to auto πŸŒ€ when progress is set to auto, a background thread runs to make sure progress is made for asynchronous requests. main character thread energy, honestly.


πŸ’€ LIMITATIONS πŸ’€

Okay so here's the ✨real talk✨ section. Sockets provider attempts to emulate the entire API set, including all defined options. and in order to support development on a wide range of systems, it's implemented over TCP sockets. as a result: the performance numbers are lower compared to other providers implemented over high-speed fabric, and lower than what an application might see implementing to sockets directly. it's giving "dev environment, not speedrun" 😭

Also, and this is important: it does not support FI_ADDR_STR address format. nope, not a thing here πŸ™…β€β™€οΈ

πŸ¦‹ RUNTIME PARAMETERS πŸ¦‹

The sockets provider checks for the following environment variables, bestie, so keep a note:

  • FI_SOCKETS_PE_WAITTIME β€” an integer value that specifies how many milliseconds to spin while waiting for progress in FI_PROGRESS_AUTO mode ⏳
  • FI_SOCKETS_CONN_TIMEOUT β€” an integer value that specifies how many milliseconds to wait for one connection establishment ⏱️
  • FI_SOCKETS_MAX_CONN_RETRY β€” an integer value that specifies the number of socket connection retries before reporting as failure πŸ”
  • FI_SOCKETS_DEF_CONN_MAP_SZ β€” an integer to specify the default connection map size πŸ—ΊοΈ
  • FI_SOCKETS_DEF_AV_SZ β€” an integer to specify the default address vector size πŸ“
  • FI_SOCKETS_DEF_CQ_SZ β€” an integer to specify the default completion queue size πŸ“š
  • FI_SOCKETS_DEF_EQ_SZ β€” an integer to specify the default event queue size πŸ“¬
  • FI_SOCKETS_DGRAM_DROP_RATE β€” an integer value to specify the drop rate of dgram frame when endpoint is FI_EP_DGRAM. this is for debugging purpose only πŸ›
  • FI_SOCKETS_PE_AFFINITY β€” if specified, progress thread is bound to the indicated range(s) of Linux virtual processor ID(s). this option is currently not supported on OS X. the usage is - id_start[-id_end[:stride]][,] 🧡
  • FI_SOCKETS_KEEPALIVE_ENABLE β€” a boolean to enable the keepalive support πŸ’“
  • FI_SOCKETS_KEEPALIVE_TIME β€” an integer to specify the idle time in seconds before sending the first keepalive probe. only relevant if FI_SOCKETS_KEEPALIVE_ENABLE is enabled ⏲️
  • FI_SOCKETS_KEEPALIVE_INTVL β€” an integer to specify the time in seconds between individual keepalive probes. only relevant if FI_SOCKETS_KEEPALIVE_ENABLE is enabled 🫢
  • FI_SOCKETS_KEEPALIVE_PROBES β€” an integer to specify the maximum number of keepalive probes sent before dropping the connection. only relevant if FI_SOCKETS_KEEPALIVE_ENABLE is enabled πŸ’”
  • FI_SOCKETS_IFACE β€” the prefix or the name of the network interface (default: any) 🌐

🧚 LARGE SCALE JOBS 🧚

For large scale runs, one can use these environment variables to set the default parameters, e.g. size of the address vector (AV), completion queue (CQ), connection map etc., that satisfies the requirement of the particular benchmark. (say that five times fast, i dare you 😭)

The recommended parameters for large scale runs are: FI_SOCKETS_MAX_CONN_RETRY, FI_SOCKETS_DEF_CONN_MAP_SZ, FI_SOCKETS_DEF_AV_SZ, FI_SOCKETS_DEF_CQ_SZ, FI_SOCKETS_DEF_EQ_SZ πŸ‘‘


🌈 SEE ALSO 🌈

go read these next, iykyk:


πŸ’œ AUTHORS πŸ’œ

OpenFabrics. β€” the icons who made it 🫢


and that's the whole page, bestie!! this was the Libfabric Programmer's Manual, dated 2024-12-10 β€” mwah, go touch some TCP sockets πŸ’‹βœ¨πŸŽ€

πŸ“¦ where this page comes from