STRUCT NVMEFC_LS_RSP(9)

🌸 NAME 🌸

okay bestie, welcome to the struct nvmefc_ls_rsp(9) page in the Kernel API Manual — and no cap, this struct is the little backstage pass for NVME-FC LS responses. It's the structure passed from the transport to the LLDD to request that the NVME-FC LS response for an NVME-FC LS request gets transmitted. It originates in the LLDD and is handed to the transport via the xxx_rcv_ls_req() transport routine. So it literally represents the FC exchange context for the NVME-FC LS request that was received and that the response is to be sent for. The LLDD uses it to pass the nvmet-fc transport (controller) received LS's such as Create Association, Create Connection and Disconnect Association. It's also used by the LLDD to pass the nvme-fc transport (host) received LS's such as Disconnect Association or Disconnect Connection. 💅

---

✨ SYNOPSIS ✨

struct nvmefc_ls_rsp {
    void *rspbuf;
    dma_addr_t rspdma;
    u16 rsplen;
    void (*done)(struct nvmefc_ls_rsp *rsp);
    void *nvme_fc_private;
};

---

🎀 Members 🎀

• rspbuf — pointer to the LS response buffer. 👑
• rspdma — PCI DMA address of the LS response buffer.
• rsplen — Length, in bytes, of the LS response buffer. 📏
• done — The callback routine the LLDD is to invoke upon completion of transmitting the LS response. The req argument is the pointer to the original ls request.
• nvme_fc_private — pointer to an internal transport-specific structure used as part of the transport done processing. The LLDD is not to access this pointer. 🚫

---

💜 Description 💜

The structure is allocated by the LLDD whenever a LS Request is received from the FC link. The address of the structure is passed to the nvmet-fc or nvme-fc layer via the xxx_rcv_ls_req transport routines. 🦋

The address of the structure is to be passed back to the LLDD when the response is to be transmit. The LLDD will use the address to map back to the LLDD exchange structure which maintains information such the remote N_Port that sent the LS as well as any FC exchange context. Upon completion of the LS response transmit, the LLDD will pass the address of the structure back to the transport LS rsp done routine, allowing the transport release dma resources. Upon completion of the done routine, no further access to the structure will be made by the transport and the LLDD can de-allocate the structure. 🫶

Field initialization: At the time of the xxx_rcv_ls_req call, there is no content that is valid in the structure.

When the structure is used for the LLDD->xmt_ls_rsp call, the transport layer will fully set the fields in order to specify the response payload buffer and its length as well as the done routine to be called upon completion of the transmit. The transport layer will also set a private pointer for its own use in the done routine.

And the page leaves us with this little cliffhanger, periodt: Values set by the transport layer prior to calling the LLDD xmt_ls_rsp entrypoint:

---

🌈 SEE ALSO 🌈

Kernel file ./include/linux/nvme-fc-driver.h — plus the whole squad: struct nvmefc_ls_req(9), struct nvme_fc_port_info(9), struct nvmefc_fcp_req(9), struct nvme_fc_local_port(9), struct nvme_fc_remote_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). 💖

---

mwah 💋 this iconic page lives under ./include/linux, dated October 2026, and it's the struct nvmefc_ls_rsp(9) manual — slay. 🌸