IBV_SRQ_PINGPONG(1)

πŸ“¦
version 65.0 Β· 2 versions
  • 65.0 Β· alpine 3.24, arch rolling, centos-stream 10, centos-stream 9, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 15.1 Β· freebsd 14.5, freebsd 15.1
, in alpine 3.24, arch rolling, centos-stream 10, centos-stream 9, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– ibv_srq_pingpong πŸ’–

okay bestie, welcome to the manual page for ibv_srq_pingpong β€” it's a USER COMMAND and it lives in section 1, and honestly? it's giving "tiny chaos gremlin that tests your InfiniBand fabric." πŸ¦‹


✨ NAME ✨

ibv_srq_pingpong β€” simple InfiniBand shared receive queue test


🌸 SYNOPSIS 🌸

ibv_srq_pingpong [-p port] [-d device] [-i ib port] [-s size] [-m size]
[-q num QPs] [-r rx depth] [-n iters] [-l sl] [-e] [-g gid index]
HOSTNAME

ibv_srq_pingpong [-p port] [-d device] [-i ib port] [-s size] [-m size]
[-q num QPs] [-r rx depth] [-n iters] [-l sl] [-e] [-g gid index]

so there's two whole moods of this command, and yes, you're allowed to just... not pass a HOSTNAME. we love options. πŸ’…


πŸŽ€ DESCRIPTION πŸŽ€

bestie, this runs a simple ping-pong test over InfiniBand using the reliable connected (RC) transport. but here's the twist that makes it special: it uses multiple queue pairs (QPs) and a single shared receive queue (SRQ). multiple QPs, one SRQ, all vibing together. it's giving group project where only one person holds the snacks. ✨


πŸ’œ OPTIONS πŸ’œ

one bullet per flag, no skipping, no summarizing, we respect the full list in this house. πŸ‘‘

  • -p, --port=PORT β€” use TCP port PORT for initial synchronization (default 18515)
  • -d, --ib-dev=DEVICE β€” use IB device DEVICE (default first device found)
  • -i, --ib-port=PORT β€” use IB port PORT (default port 1)
  • -s, --size=SIZE β€” ping-pong messages of size SIZE (default 4096)
  • -m, --mtu=SIZE β€” path MTU SIZE (default 1024)
  • -q, --num-qp=NUM β€” use NUM queue pairs for test (default 16)
  • -r, --rx-depth=DEPTH β€” post DEPTH receives at a time (default 1000)
  • -n, --iters=ITERS β€” perform ITERS message exchanges (default 1000)
  • -l, --sl=SL β€” use SL as the service level value of the QPs (default 0)
  • -e, --events β€” sleep while waiting for work completion events (default is to poll for completions)
  • -g, --gid-idx=GIDINDEX β€” local port GIDINDEX
  • -c, --chk β€” validate received buffer

that's twelve options, we counted, we did not lose a single one, periodt. 🌈


πŸ¦‹ SEE ALSO πŸ¦‹

go bother these siblings next, they're all family:


πŸ‘‘ AUTHORS πŸ‘‘

Roland Dreier β€” <rolandd@cisco.com> πŸ’–


πŸ’€ BUGS πŸ’€

okay so, real talk, no cap, we have to be honest here because this is the important part:

The network synchronization between client and server instances is weak, and does not prevent incompatible options from being used on the two instances. The method used for retrieving work completions is not strictly correct, and race conditions may cause failures on some systems.

so like… it might be a little messy. 😭 not me warning you about actual race conditions. read that again before you blame yourself. it's not you, it's the synchronization. πŸ™ˆ


and that's the whole page bestie!! this manual page came from libibverbs, and it's dated August 30, 2005 β€” yeah, 2005, it's vintage, it's an icon, it walked so we could run. 🧚 ty for reading, go ping some pongs, ily πŸ’œ

πŸ“¦ where this page comes from