STRUCT NVME_FC_REMOTE_PORT(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct nvme_fc_remote_port(9)

okay so this is a page from the Kernel API Manual (yes, the kernel has its own manual, we stay educated πŸ’–), and it's all about struct nvme_fc_remote_port β€” the little data structure that gets passed between the NVME-FC transport and a LLDD so they can both point at a remote NVME subsystem port. It's allocated/created by the nvme_fc_register_remoteport() transport interface. That's the whole vibe. πŸ¦‹


✨ SYNOPSIS ✨

struct nvme_fc_remote_port {
    u32 port_num;
    u32 port_role;
    u64 node_name;
    u64 port_name;
    struct nvme_fc_local_port *localport;
    void *private;
    u32 dev_loss_tmo;
    u32 port_id;
    enum nvme_fc_obj_state port_state;
 };

πŸŽ€ Members πŸŽ€

okay bestie let's go field by field, no skips, we're thorough here πŸ‘‘

  • port_num β€” the NVME-FC transport remote subsystem port number. it's giving "which port" energy.
  • port_role β€” the NVME roles that are supported on the port (peep FC_PORT_ROLE_xxx for the actual options, iykyk).
  • node_name β€” the FC WWNN for the port. iconic identifier, fr fr.
  • port_name β€” the FC WWPN for the port. yes it's a different name than node_name, they're different things, don't mix them up πŸ’€
  • localport β€” pointer to the NVME-FC local host port that the subsystem is connected to.
  • private β€” pointer to memory allocated alongside the remote port structure, and this chunk is specifically for the LLDD to use. the length of that buffer corresponds to the remote_priv_sz value that the LLDD supplies in the nvme_fc_port_template. 🫢
  • port_id β€” the FC N_Port_ID currently assigned to the port. the upper 8 bits must be set to 0 β€” that part is a hard requirement, not a suggestion, so please actually do it πŸ™ˆ
  • port_state β€” the operational state of the remote port. valid values are ONLINE or UNKNOWN. that's the whole vibe check. ⭐

🌸 Description 🌸

so there's two flavours of fields living in here:

Fields with static values for the port. these get initialized by the port_info struct that gets supplied to the registration call.

Fields with dynamic values. these ones can change based on link state or login state, and the LLDD may reference the fields directly to change them. they're also initialized by the port_info struct supplied to the registration call. so like, same origin story, different energy going forward. πŸ’«


πŸ”₯ SEE ALSO πŸ”₯

go read these next, bestie, they're all in the kernel file ./include/linux/nvme-fc-driver.h:

  • struct nvmefc_ls_req(9)
  • struct nvmefc_ls_rsp(9)
  • struct nvme_fc_port_info(9)
  • struct nvmefc_fcp_req(9)
  • struct nvme_fc_local_port(9)
  • struct nvme_fc_port_template(9)
  • struct nvmet_fc_port_info(9)
  • struct nvmefc_tgt_fcp_req(9)
  • struct nvmet_fc_target_port(9)
  • struct nvmet_fc_target_template(9)

ngl the whole family of these structs lives under ./include/linux, so if you're lost, that's your first stop 🧚

and that's the page, periodt πŸ’œ this cutie lives in ./include/linux, and the version we're stanning is dated October 2026 β€” mwah, go forth and register those remote ports responsibly πŸŽ€βœ¨

πŸ“¦ where this page comes from