fcoe_ctlr_vn_parse(9)

💖 fcoe_ctlr_vn_parse(9) — Kernel API Manual vibes ✨

okay bestie, so this is a page straight outta the Kernel API Manual, and it's about one tiny lil function that does a very specific thing. it's not the whole show, it's one icon in the cast, and honestly? it ate. let's get into it 🫶

---

🌸 NAME 🌸

fcoe_ctlr_vn_parse — parse probe request or response

like literally that's it. that's the whole job. it looks at a probe request or a probe response and figures out what's inside. lowkey iconic of it 💅

---

✨ SYNOPSIS ✨

int fcoe_ctlr_vn_parse (struct fcoe_ctlr *fip , struct sk_buff *skb ,
struct fcoe_rport *frport );

the way it returns an int... we love a function that tells you how it's feeling 😭

---

🎀 ARGUMENTS 🎀

• fip — The FCoE controller. this is the main character of the whole FCoE situation, and our girl needs a pointer to it. struct fcoe_ctlr *, no cap 💜
• skb — incoming packet. the actual data arriving, all wrapped up in a struct sk_buff *. this is the thing getting parsed, she's the guest of honor 🦋
• frport — parsed FCoE rport from the probe request. this is where the info lands after the parse — a struct fcoe_rport * that gets filled in. it's giving "output parameter" and we're obsessed 🌈

---

🔥 DESCRIPTION 🔥

so here's the tea ☕ — this function returns a non-zero error number on error. non-zero means something went sideways, zero means we're slaying. that's the whole vibe check on the return value fr fr.

and the big one, the detail you CANNOT sleep on: it does not consume the packet. like, the packet is still there after. it's not eaten, not freed, not destroyed — she just looks 👀. so don't go freeing that skb thinking this function handled it, because she did NOT, and that would be a whole situation 💀

bestie please remember the "does not consume the packet" part. it's like three words in the original and it's the most important three words. losing track of packet ownership is how you get kernel oops energy and nobody wants that 🙈

---

👑 SEE ALSO 👑

okay so this function doesn't exist in a vacuum — she's part of a whole friend group 💖. the kernel file in question is ./drivers/scsi/fcoe/fcoe_ctlr.c, and here is the FULL squad, every single one, no skips, no cuts, periodt:

fcoe_ctlr_set_state(9), fcoe_ctlr_mtu_valid(9), fcoe_ctlr_fcf_usable(9),
fcoe_ctlr_map_dest(9), fcoe_ctlr_init(9), fcoe_sysfs_fcf_add(9),
fcoe_sysfs_fcf_del(9), fcoe_ctlr_reset_fcfs(9), fcoe_ctlr_destroy(9),
fcoe_ctlr_announce(9), fcoe_ctlr_fcoe_size(9), fcoe_ctlr_solicit(9),
fcoe_ctlr_link_up(9), fcoe_ctlr_reset(9), fcoe_ctlr_link_down(9),
fcoe_ctlr_send_keep_alive(9), fcoe_ctlr_encaps(9), fcoe_ctlr_els_send(9),
fcoe_ctlr_age_fcfs(9), fcoe_ctlr_parse_adv(9), fcoe_ctlr_recv_adv(9),
fcoe_ctlr_recv_els(9), fcoe_ctlr_recv_clr_vlink(9), fcoe_ctlr_recv(9),
fcoe_ctlr_recv_handler(9), fcoe_ctlr_select(9),
fcoe_ctlr_flogi_send_locked(9), fcoe_ctlr_flogi_retry(9),
fcoe_ctlr_flogi_send(9), fcoe_ctlr_timeout(9), fcoe_ctlr_timer_work(9),
fcoe_ctlr_recv_work(9), fcoe_ctlr_recv_flogi(9), fcoe_wwn_from_mac(9),
fcoe_ctlr_rport(9), fcoe_ctlr_vn_send(9), fcoe_ctlr_vn_rport_callback(9),
fcoe_ctlr_disc_stop_locked(9), fcoe_ctlr_disc_stop(9),
fcoe_ctlr_disc_stop_final(9), fcoe_ctlr_vn_restart(9),
fcoe_ctlr_vn_start(9), fcoe_ctlr_vn_send_claim(9),
fcoe_ctlr_vn_probe_req(9), fcoe_ctlr_vn_probe_reply(9),
fcoe_ctlr_vn_add(9), fcoe_ctlr_vn_lookup(9),
fcoe_ctlr_vn_claim_notify(9), fcoe_ctlr_vn_claim_resp(9),
fcoe_ctlr_vn_beacon(9), fcoe_ctlr_vn_age(9), fcoe_ctlr_vn_recv(9),
fcoe_ctlr_vlan_parse(9), fcoe_ctlr_vlan_send(9),
fcoe_ctlr_vlan_disc_reply(9), fcoe_ctlr_vlan_recv(9),
fcoe_ctlr_disc_recv(9), fcoe_ctlr_vn_disc(9), fcoe_ctlr_vn_timeout(9),
fcoe_ctlr_mode_set(9), fcoe_libfc_config(9)

that's a lot of friends and honestly? she's booked and busy 🧚 iykyk 💅

---

⭐ cute lil sign-off ⭐

this lil page lives under ./drivers/scsi/fcoe, it's dated October 2026, and it's page fcoe_ctlr_vn_parse(9) of the Kernel API Manual — so like, go forth, parse your probe requests, and don't consume the packet bestie 🍓💖✨