nvmet_fc_rcv_fcp_req(9)

💖 nvmet_fc_rcv_fcp_req(9) 💖

okay so bestie, welcome to the Kernel API Manual ✨ this one is nvmet_fc_rcv_fcp_req(9) and it is literally the glow-up era of Fibre Channel NVMe target land 🦋

---

🌸 NAME 🌸

nvmet_fc_rcv_fcp_req — the transport entry point that an LLDD calls when it receives an NVME FCP CMD IU. yeah. that's the whole vibe. iykyk 💅

---

✨ SYNOPSIS ✨

int nvmet_fc_rcv_fcp_req (struct nvmet_fc_target_port *target_port ,
struct nvmefc_tgt_fcp_req *fcpreq , void *cmdiubuf , u32 cmdiubuf_len );

like, four args, one int. no cap, that's it 🎀

---

🎀 ARGUMENTS 🎀

• target_port — pointer to the (registered) target port that the FCP CMD IU was received on. it's the one who caught the vibe check 🫶
• fcpreq — pointer to a fcpreq request structure, used to reference the exchange that corresponds to the FCP Exchange. this is the main character energy of the exchange ngl 👑
• cmdiubuf — pointer to the buffer holding the FCP CMD IU. the actual payload bestie 💜
• cmdiubuf_len — length, in bytes, of the received FCP CMD IU. yes, u32. yes, in bytes. we love a units clarification 🌈

---

🦋 DESCRIPTION 🦋

so what this does is: it passes a FC-NVME FCP CMD IU that came in from the FC link over to the nvmet-fc layer for processing. handing it off. slay ✨

the nvmet_fc layer allocates a local job structure (struct nvmet_fc_fcp_iod) from the queue for the io, and copies the CMD IU buffer into that job structure. so — heads up — on a successful completion (meaning it returns 0), the LLDD may immediately free or reuse the CMD IU buffer it passed into the call. no lingering, no hard feelings, periodt 💅

but 😭 — and this is the however — in some circumstances, because FC is packetized and because of the API of the FC LLDD, which may issue a hw command to send the response, the LLDD may not get the hw completion for that command and upcall the nvmet_fc layer before a new command may be asynchronously received. which means it's possible for a command to be received before the LLDD and nvmet_fc have recycled the job structure. it gives the whole appearance of more commands received than fits in the sq 💀

to alleviate this scenario, a temporary queue is maintained in the transport for pending LLDD requests that are waiting on a queue job structure. in these "overrun" cases, a temporary queue element is allocated, the LLDD request and CMD iu buffer information are remembered, and the routine returns a -EOVERFLOW status. iconic behavior tbh 🍓

subsequently, when a queue job structure is freed, it's immediately reallocated for anything on the pending request list. the LLDD's defer_rcv callback gets called, informing the LLDD that it may reuse the CMD IU buffer, and the io is then started normally with the transport. the way that works is just chef's kiss 🧚

⚠️ bestie read this twice: the LLDD, when it receives a -EOVERFLOW completion status, is to treat the completion as successful — BUT it must not reuse the CMD IU buffer until the LLDD's defer_rcv callback has been called for the corresponding struct nvmefc_tgt_fcp_req pointer. do not skip this step. i'm serious. 🙈

if there's any other condition in which an error occurs, the transport will return a non-zero status indicating the error. and in all cases other than -EOVERFLOW, the transport has not accepted the request, and the LLDD should abort the exchange. yes, abort. no "maybe it'll be fine". it will not be fine 😤🔥

---

💀 SEE ALSO 💀

• Kernel file ./drivers/nvme/target/fc.c
• nvmet_fc_register_targetport(9)
• nvmet_fc_invalidate_host(9)
• nvmet_fc_unregister_targetport(9)
• nvmet_fc_rcv_ls_req(9)
• nvmet_fc_rcv_fcp_abort(9)

like, go read the whole friend group honestly, they all ate 🌟

---

💌 ok that's the page!! brought to you by ./drivers/nvme/target, dated October 2026, and yes the title is nvmet_fc_rcv_fcp_req(9) — mwah, love u, go recycle your job structures responsibly 🫶💖🎀