libnvme(9)

💅 libnvme(9) — API Manual, bestie edition ✨

okay so this is libnvme(9), the API manual, and today's main character is a struct that's lowkey the whole personality of an NVMe/TCP boot setup. it lives in the libnvme API manual and it is so specific. buckle up 🎀

🌸 NAME 🌸

struct libnbft_hfi_info_tcp — the HFI Transport Info Descriptor for NVMe/TCP. that's it, that's the vibe 💖

✨ SYNOPSIS ✨

struct libnbft_hfi_info_tcp {
    __u32 pci_sbdf;
    __u8 mac_addr[6];
    __u16 vlan;
    __u8 ip_origin;
    char ipaddr[40];
    __u8 subnet_mask_prefix;
    char gateway_ipaddr[40];
    __u16 route_metric;
    char primary_dns_ipaddr[40];
    char secondary_dns_ipaddr[40];
    char dhcp_server_ipaddr[40];
    char *host_name;
    __u8 flags;
    __u8 pcie_seg_num;
    __u32 dhcp_iaid;
    __u8 dhcp_duid[130];
    __u8 dhcp_duid_len;
 };

look at her. seventeen fields. zero notes. iconic 👑

🦋 Members 🦋

bestie, here's every single member, no skips, no "you get the idea" — we do not do that here 🙅‍♀️

• pci_sbdf — the PCI Express Routing ID for the HFI Transport Function. that's the "where do i even find this thing on the bus" field 🚌
• mac_addr — MAC Address: literally the MAC address of this HFI, in EUI-48TM format. six bytes of pure identity 💅
• vlan — the VLAN identifier if the VLAN is associated with this HFI, as defined in IEEE 802.1q-2018, or zeroes if no VLAN is associated with this HFI. no vlan? it's giving zeroes 🌸
• ip_origin — the source of the Ethernet L3 configuration information used by the driver, or 0 if not used. so like, where did the IP config come from, and 0 means "nobody, it's not used" 🫶
• ipaddr — the IPv4 or IPv6 address of this HFI. yes either one, she contains multitudes ✨
• subnet_mask_prefix — the IPv4 or IPv6 subnet mask in CIDR routing prefix notation. the slash-number energy 🌈
• gateway_ipaddr — the IPv4 or IPv6 address of the IP gateway for this HFI, or zeroes if no IP gateway is specified. no gateway? zeroes. we stan a consistent default 💖
• route_metric — the cost value for the route indicated by this HFI. it's the toll fee for your packets, fr fr 🛣️
• primary_dns_ipaddr — the IPv4 or IPv6 address of the Primary DNS server for this HFI. the first bestie you ask for directions 🔥
• secondary_dns_ipaddr — the IPv4 or IPv6 address of the Secondary DNS server for this HFI. the backup bestie, still valid, still loved 🫂
• dhcp_server_ipaddr — the IPv4 or IPv6 address of the DHCP server used to assign this HFI address. shoutout to the server that handed out the lease 🎀
• host_name — the Host Name string. note that she's a char *, a pointer, miss independent 💫
• flags — HFI Transport Flags bitmask, see enum nbft_hfi_info_tcp_flags. bitmask behaviour, always check the enum, iykyk 🚩
• pcie_seg_num — the PCIe Segment Number for the HFI Transport Function when the PCI Express Link is in Flit mode. it's Zero if not in Flit mode, not supported, or the NBFT data originates from a pre-NBFT rev. 1.1 driver. so many reasons to be zero and honestly same 😭
• dhcp_iaid — the DHCP Identity Association Identifier (IAID) as defined in RFC 4361. the IAID is a 32-bit value that uniquely identifies the client's network interface for DHCP purposes. NBFT rev. 1.1+; meaningful when dhcp_duid_len is non-zero. so if dhcp_duid_len is zero, this girl is not speaking to you 💀
• dhcp_duid — the raw DHCP Unique Identifier (DUID) as defined in RFC 8415 section 11 (NBFT rev. 1.1+). this is the complete DUID including its leading 2-byte type code followed by up to 128 bytes of type-specific identifier data. the known DUID type codes are: 1 (DUID-LLT, link-layer address plus time), 2 (DUID-EN, vendor-assigned based on enterprise number), 3 (DUID-LL, link-layer address), 4 (DUID-UUID, universally unique identifier). multi-byte fields within the DUID are stored in little-endian byte order as specified by the NVMe Boot Specification. the consumer is responsible for parsing the type code and the type-specific data. this is a local copy of the data from the NBFT heap. this array is zero-filled when the DUID is not present; check dhcp_duid_len. okay that was a lot but every word of it matters, do not skip the parsing part, the parsing part is on you 🫵
• dhcp_duid_len — the number of valid bytes in dhcp_duid, ranging from 3 (minimum: 2-byte type code plus at least 1 byte of data) to 130 (maximum per RFC 8415). NBFT rev. 1.1+. a value of zero indicates that no DUID is present and both dhcp_duid and dhcp_iaid should be ignored. so zero means ignore both, periodt 🚫

⚠️ real talk: dhcp_duid is a local copy from the NBFT heap, it's zero-filled when there's no DUID, and you are the one parsing the type code and the type-specific data. nobody's doing that for you, bestie. check dhcp_duid_len first, always 💖

and that's the whole page, no cap. this was struct libnbft_hfi_info_tcp from the libnvme(9) API manual, dated October 2026 — go forth and parse those DUIDs with main character energy 🦋💅✨