SRP_DAEMON(8)

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

πŸ’– SRP_DAEMON(8) πŸ’–

okay bestie, welcome to srp_daemon β€” she lives in section 8 of the manual (that's the admin/user commands zone) and she's here to find SRP targets in an InfiniBand Fabric. yes, that's the NAME. iconic. let's go ✨


🌈 SYNOPSIS 🌈

srp_daemon [-vVcaeon] [-d umad-device | -i infiniband-device [-p port-
num] | -j dev:port] [-t timeout(ms)] [-r retries] [-R rescan-time] [-f
rules-file]

that's the whole vibe right there. copy it, love it, use it πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

so basically: srp_daemon discovers and connects to InfiniBand SCSI RDMA Protocol (SRP) targets in an IB fabric. she's a finder, she's a connector, she's doing the most 🫢

each srp_daemon instance works on one local port. on boot she does a full rescan of the fabric, and then she just… waits. for an srp_daemon event. and what counts as an srp_daemon event, you ask? literally any of these:

  • a new machine joins the fabric
  • a machine's capabilities change
  • an SA change
  • a predefined timeout expiring

and here's how she reacts, no cap:

  • new machine joins the fabric β†’ srp_daemon checks if it's an SRP target
  • capabilities change β†’ srp_daemon checks if that machine has turned into an SRP target
  • SA change or timeout expiration β†’ srp_daemon performs a full rescan of the fabric

then, for every target she finds, she does a lil vibe check: should she connect to it according to her rules (default rules file is /etc/srp_daemon.conf, fyi), and is she already connected to the local port? and if the answer is "yes should connect" + "no not connected yet", then srp_daemon can either print the target details or actually connect to it. main character energy honestly πŸ‘‘


✨ OPTIONS ✨

  • -v β€” print more verbose output. she's talking more now πŸ’¬
  • -V β€” print even more verbose output (debug mode). full yapper mode, we love to see it πŸ—£οΈ
  • -i infiniband-device β€” work on infiniband-device. do not use this one with -d and do not use it with -j. pick a lane bestie πŸ™ˆ
  • -p port-num β€” work on port port-num (default 1). this one must be used with -i, and should not be used with -d nor with -j. she's taken, she only goes with -i πŸ’–
  • -j dev:port β€” work on port number port of InfiniBand device dev. this one should not be used with -d, -i nor with -p. solo act, no features πŸŽ€
  • -d umad-device β€” use device file umad-device (default /dev/infiniband/umad0). this one should not be used with -i, -p nor with -j. also very much a lone wolf ⭐
  • -c β€” generate output that's suitable for piping directly into a /sys/class/infiniband_srp/srp-<device>-<port>/add_target file. plug and play, literally πŸ”₯
  • -a β€” prints all the targets in the fabric, not only the targets that aren't connected through the local port. this is the same behavior as ibsrpdm's. give me everything, no filter 😌
  • -e β€” execute the connection command, i.e. actually make the connection to the target. she's not just looking, she's doing πŸ’…
  • -o β€” perform only one rescan and exit, just like ibsrpdm. one and done, in and out 🧚
  • -R rescan-time β€” force a complete rescan every rescan-time seconds. if -R is not specified, no timeout rescans will be performed. (so if you don't ask for it, it's not happening, periodt)
  • -T retry-timeout β€” retries to connect to an existing target after retry-timeout seconds. if -R is not specified, uses 5 Seconds timeout. if retry-timeout is 0, will not try to reconnect. the reason srp_daemon retries to connect to the target is because there may be a rare scnerio in which srp_daemon will try to connect to add a target when the target is about to be removed, but is not removed yet. messy situation, she handles it 😭
  • -f rules-file β€” decide which targets to connect to according to the rules in rules-file. if -f is not specified, uses the default rules file /etc/srp_daemon.conf. each line in the rules-file is a rule, and it can be either an allow connection or a disallow connection, depending on the first character in the line (a or d accordingly). the rest of the line is values for id_ext, ioc_guid, dgid, service_id. pls take a look at the example section for an example of the file πŸ‘€. srp_daemon decides whether to allow or disallow each target according to the first rule that matches the target. if no rule matches the target, the target is allowed and will be connected (generous queen 🌸). and in an allow rule you can set attributes for the connection to the target β€” supported attributes are max_cmd_per_lun and max_sect ✨
  • -t timeout β€” use a timeout of timeout msec for MAD responses (default: 5 sec). patience levels: adjustable ⏳
  • -r retries β€” perform retries retries on each send to MAD (default: 3 retries). she tries again, she tries again, she tries again πŸ’ͺ
  • -n β€” new format β€” also use initiator_ext in the connection command. glow up version πŸ’«
  • --systemd β€” enable systemd integration. teaming up with the system, collab era 🀝

πŸ“ FILES πŸ“

  • /etc/srp_daemon.conf β€” the default rules configuration file that tells her which targets to connect to. can be overridden using the -f rules-file option. each line in this file is a rule, which can be either an allow connection or a disallow connection, according to the first character in the line (a or d accordingly). the rest of the line is values for id_ext, ioc_guid, dgid, service_id. pls take a look at the example section for an example of the file πŸ‘€. srp_daemon decides whether to allow or disallow each target according to the first rule that matches the target. if no rule matches the target, the target is allowed and will be connected. in an allow rule it is possible to set attributes for the connection to the target β€” supported attributes are max_cmd_per_lun and max_sect. yes this is the same info as the -f option, we're just being thorough bestie πŸ’œ

🌸 EXAMPLES 🌸

okay these are the real ones, watch closely:

srp_daemon -e -i mthca0 -p 1 -R 60

(Connects to the targets accessible through port 1 of mthca0. Performs a complete rescan every minute)

srp_daemon -o -c -a

(Prints the connection commands for the targets in the fabric and exits β€” similar to ibsrpdm)

srp_daemon -e -f rules.txt

(Connects to the targets allowed in the rules file rules.txt)

and now… the moment you've been waiting for. an example for a rules configuration file (such as /etc/srp_daemon.conf):

# Rules file example
# This is a comment
# disallow the following dgid
d       dgid=fe800000000000000002c90200402bd5
# allow target with the following ioc_guid
a       ioc_guid=00a0b80200402bd7
# allow target with the following id_ext and ioc_guid. And setting max_cmd_per_lun to 31.
a       id_ext=200500A0B81146A1,ioc_guid=00a0b80200402bef,max_cmd_per_lun=31
# disallow all the rest
d

πŸ‘€ SEE ALSO πŸ‘€


πŸ’– AUTHORS πŸ’–

the literal legends who made this happen:

  • Roland Dreier <rolandd@cisco.com>
  • Ishai Rabinovitz <ishai@mellanox.co.il>

and that's the whole page, bestie!! this one's brought to you by OpenFabrics, dated September 5, 2006 β€” yeah she's an elder but she still eats, no cap πŸ’…βœ¨πŸ¦‹

πŸ“¦ where this page comes from