IBV_RC_PINGPONG(1)

πŸ“¦
version 62.0 Β· 3 versions
, in alpine 3.24, centos-stream 10, centos-stream 9, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, opensuse-leap 16.0, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute

πŸ’– ibv_rc_pingpong πŸ’–

okay bestie, gather round, because today we're talking about ibv_rc_pingpong β€” a little tool from the libibverbs fam that runs a simple ping-pong test over InfiniBand using the reliable connected (RC) transport. yes, RC like really committed, unlike some transports we could name. 🫢


✨ NAME ✨

ibv_rc_pingpong β€” simple InfiniBand RC transport test, no cap


πŸŽ€ SYNOPSIS πŸŽ€

ibv_rc_pingpong [-p port] [-d device] [-i ib port] [-s size] [-m size]
[-r rx depth] [-n iters] [-l sl] [-e] [-g gid index] [-o] [-P] [-t] [-j]
[-N] HOSTNAME

ibv_rc_pingpong [-p port] [-d device] [-i ib port] [-s size] [-m size]
[-r rx depth] [-n iters] [-l sl] [-e] [-g gid index] [-o] [-P] [-t] [-j]
[-N]

like, one of these has a HOSTNAME and one doesn't. that's the whole difference. one is the server main character, one is the client. you'll figure it out πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

Run a simple ping-pong test over InfiniBand via the reliable connected (RC) transport.

that's it. that's the vibe. you bounce messages back and forth over RC and see how it goes. it's giving networking but make it a duet ✨


🌸 OPTIONS 🌸

so many flags, so little time. let's go one by one, bestie, because none of these are optional to know about:

  • -p, --port=PORT β€” use TCP port PORT for initial synchronization (default 18515). this is just the lil handshake so the two sides can find each other, it's not the IB magic itself 😌
  • -d, --ib-dev=DEVICE β€” use IB device DEVICE (default is the first device found). if you don't pick one, it just grabs whatever shows up first, iconic behavior honestly
  • -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)
  • -r, --rx-depth=DEPTH β€” post DEPTH receives at a time (default 1000). like, queue up a whole stack of them πŸ“
  • -n, --iters=ITERS β€” perform ITERS message exchanges (default 1000)
  • -l, --sl=SL β€” use SL as the service level value of the QP (default 0)
  • -e, --events β€” sleep while waiting for work completion events (default is to poll for completions). so instead of spinning like an overcaffeinated gremlin, you nap until something happens 😴
  • -g, --gid-idx=GIDINDEX β€” local port GIDINDEX
  • -o, --odp β€” use on demand paging
  • -P, --prefetch= β€” prefetch an ODP MR
  • -t, --ts β€” get CQE with timestamp
  • -c, --chk β€” validate received buffer. yes queen, verify your data πŸ”
  • -j, --dm β€” use device memory
  • -N, --new_send β€” use new post send WR API

πŸ’œ SEE ALSO πŸ’œ

the whole pingpong cinematic universe, fr fr:


πŸ‘‘ AUTHORS πŸ‘‘

Roland Dreier β€” <rolandd@cisco.com>

thank you for your service, king 🫑✨


πŸ’€ BUGS πŸ’€

okay so this is the part where we're honest, and ngl it's a little messy:

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.

translation: the two sides are texting each other with no read receipts, and if you give them mismatched options they will simply Not Notice. and the completion-fetching method has some race-condition chaos in it. so like, be aware. not me warning you though πŸ™ˆ


and that's the whole page, bestie!! this one came from libibverbs, dated August 30, 2005 β€” a true elder of the networking world, still out here bouncing packets. periodt. πŸ’–πŸŒˆβ­

πŸ“¦ where this page comes from