CMTIME(1)

๐Ÿ“ฆ
version 65.0 ยท 3 versions
, in alpine 3.24, arch rolling, centos-stream 10, centos-stream 9, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu resolute, ubuntu stonking

๐Ÿ’– CMTIME(1) โ€” the cmtime glow-up ๐Ÿ’–

okay bestie, welcome to cmtime, straight outta librdmacm โ€” it's the RDMA CM connection-steps timing test and she is literally here to clock every single step of your connection setup and teardown. grab a snack, we're benchmarking โœจ


๐ŸŒธ NAME ๐ŸŒธ

cmtime โ€” RDMA CM connection steps timing test. that's it, that's the vibe ๐Ÿ’…


๐ŸŽ€ SYNOPSIS ๐ŸŽ€

cmtime -C controller_address
          (-B bind_interface | -b bind_address)
          [-L]
          [-c connections_per_pair] [-P num_peers]
          [-p controller_port]
          [-q base_qpn] [-n num_threads]
          [-m mimic_qp_delay_us] [-r retries]
          [-t timeout_ms]
          [-S]

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

so what does she actually do?? she figures out the min, max, and average times for all the various "steps" in RDMA CM connection setup and teardown, running between clients and servers. no cap, that's the whole job and she eats every time ๐Ÿ”ฅ

to use it, you start one or more servers (that's the -L flag bestie) plus one or more clients. each client will establish -c number of connections to each server. by default, the test runs with 1 client and 1 server. simple, cute, efficient ๐Ÿ’–

one process is gonna act as the controller process. the controller coordinates the clients and servers โ€” she uses out-of-band sockets to collect and distribute addresses and keeps clients and servers in sync as they advance through each "step". she's the group chat admin of this operation fr fr ๐Ÿ‘‘

the "steps" that get timed are, in order:

  1. create ID
  2. bind address
  3. resolve address
  4. resolve route
  5. create QP
  6. modify QP to INIT
  7. modify QP to RTR
  8. modify QP to RTS
  9. CM connect
  10. client establish
  11. disconnect
  12. destroy QP
  13. destroy ID

the way that so many operations are asynchronous, allowing progress on multiple connections simultaneously?? iconic. the sum output adds the time that all connections took for a given step. the average us/conn is the sum divided by the number of connections. this is useful to identify steps which take a significant amount of time. the min and max values are the smallest and largest times that any single connection took to complete a given step.

and now the total and avg/iter times โ€” those measure the time to complete a given step for all connections. these two values take into account asynchronous operations. for steps which are serial, the total and sum values will be roughly the same. for asynchronous steps, the total may be significantly lower than the sum, as multiple connections will be in progress simultaneously. the avg/iter is the total time divided by the number of connections. math girlies rise ๐Ÿงฎโœจ

ngl, in many cases times may not be available or only available on the clients. in such situations, the output will show 0. stats printed by each instance pertain to connections handled by it โ€” on runs with multiple clients and/or servers (-P > 2) further external aggregation might be required. so yeah, you might have to do a lil manual math, sorry babe ๐Ÿ˜ญ

โœจ OPTIONS โœจ

  • -C controller_address โ€” the network name or IP address of the instance which will provide step synchronization. this option must be specified by all instances. the first instance to start which discovers this address as local will act as controller and will synchronize all other instances via an out-of-band channel as benchmark steps progress. any type of instance (client or server) can act as controller. everybody's welcome in the controller seat ๐Ÿซถ
  • -B bind_interface โ€” the local RDMA interface to bind to. only one of -B or -b is accepted. pick a lane bestie.
  • -b bind_address โ€” the local network address to bind to. only one of -B or -b is accepted. same energy, different flavor.
  • -L โ€” whether this instance is an RDMA CM server (set) or client (unset). (default client/unset). flip the switch and you're a server now, main character energy ๐Ÿ‘‘
  • -c connections_per_pair โ€” the number of connections to establish between each client-server pair. (default 100). go big or go home.
  • -P num_peers โ€” total number of peers (clients, servers) which are going to be started. (default 2). the whole squad, counted.
  • -p controller_port โ€” the controller's port number. her personal line ๐Ÿ’…
  • -q base_qpn โ€” the first QP number to use when creating connections without allocating hardware QPs. the test will use the values between base_qpn and base_qpn plus connections when connecting. (default 1000).
  • -n num_threads โ€” sets the number of threads to spawn used to process connection events and hardware operations. (default 1).
  • -m mimic_qp_delay_us โ€” "simulates" QP creation and modify calls by replacing them with a simple sleep function instead. this allows testing the CM at larger scale than would be practical, or even possible given system configuration settings, if HW resources needed to be allocated. fake it till you make it, the hardware never has to know ๐Ÿ™ˆ
  • -r retries โ€” number of retries when resolving address or route. (default 2). she's persistent, she's trying again ๐Ÿ’œ
  • -S โ€” run connection rate test using sockets. this provides a baseline comparison of RDMA connections versus TCP connections. sockets are set to blocking mode. only supported in 1 client 1 server mode (-P 2). do not try to be slick with other peer counts, it will not work ๐Ÿšซ
  • -t timeout_ms โ€” timeout in millseconds (ms) when resolving address or route. (default 2000 - 2 seconds).

๐ŸŒˆ EXAMPLES ๐ŸŒˆ

one client connecting to one server:

server$ cmtime -B enp1s0f0np0 -C 192.0.2.1 -L
client$ cmtime -B enp1s0f0np0 -C 192.0.2.1

two clients connecting to three servers, 6k connections in total:

client1$ cmtime -B enp1s0f0np0 -P 5 -C 192.0.2.1 -c 1000
client2$ cmtime -B enp1s0f0np0 -P 5 -C 192.0.2.1 -c 1000
server1$ cmtime -B enp1s0f0np0 -P 5 -C 192.0.2.1 -c 1000 -L
server2$ cmtime -B enp1s0f0np0 -P 5 -C 192.0.2.1 -c 1000 -L
server3$ cmtime -B enp1s0f0np0 -P 5 -C 192.0.2.1 -c 1000 -L

๐Ÿ’€ NOTES ๐Ÿ’€

because this test maps RDMA resources to userspace, users must ensure that they have available system resources and permissions. see the libibverbs README file for additional details. like, actually read it, don't just scroll past ๐Ÿ‘€


๐Ÿ”ฅ SEE ALSO ๐Ÿ”ฅ

rdma_cm(7) โ€” go read that one too, she's the lore.


this page lives in <strong>librdmacm</strong>, dated <strong>2025-09-03</strong> ๐ŸŽ€ stay slay, go measure some connections, and remember: every step deserves her moment in the spotlight โœจ๐Ÿ’–๐Ÿฆ‹

๐Ÿ“ฆ where this page comes from