STRUCT TBNET(9)

✨ struct tbnet — the ThunderboltIP network driver's private data, bestie ✨

okay so this is a page from the Kernel API Manual (section 9, kernel-adjacent girlies rise up 💅), and it's all about struct tbnet. That's the private data blob for the ThunderboltIP network driver. Not public, not for you to poke at, just the driver's own little diary 🎀

---

🦋 NAME

struct tbnet — the ThunderboltIP network driver's private data. That's it, that's the whole vibe. It's the driver's personal info stash, no cap.

---

🌸 SYNOPSIS

here's the whole struct, literally copy-pasted with love so you don't have to squint at the source:

struct tbnet {
    const struct tb_service *svc;
    struct tb_xdomain *xd;
    struct tb_protocol_handler handler;
    struct net_device *dev;
    struct napi_struct napi;
    struct tbnet_stats stats;
    struct sk_buff *skb;
    atomic_t command_id;
    bool login_sent;
    bool login_received;
    int local_transmit_path;
    int remote_transmit_path;
    struct mutex connection_lock;
    int login_retries;
    struct delayed_work login_work;
    struct work_struct connected_work;
    struct work_struct disconnect_work;
    struct thunderbolt_ip_frame_header rx_hdr;
    struct tbnet_ring rx_ring;
    atomic_t frame_id;
    struct tbnet_ring tx_ring;
 };

---

👑 Members

okay bestie, member-by-member tour, let's go 🫶

• svc — the XDomain service this driver is bound to. Like, the service it said "yes, I'm yours" to.
• xd — the XDomain that the service belongs to. The bigger picture, the main character it lives inside ✨
• handler — the ThunderboltIP configuration protocol handler. It handles the config protocol, periodt.
• dev — the networking device. your actual net device, hi bestie 👋
• napi — the NAPI structure used for Rx polling. NAPI is out here doing the polling for receives.
• stats — network statistics. the receipts 📊
• skb — the network packet that is currently being processed on the Rx path. one packet at a time, it's giving focus 💅
• command_id — the ID used for the next configuration protocol packet.
• login_sent — the ThunderboltIP login message was successfully sent. slay, it went out 🚀
• login_received — the ThunderboltIP login message was received from the remote host. and they said hi back 😭
• local_transmit_path — the HopID we are using to send out packets.
• remote_transmit_path — the HopID the other end is using to send packets to us.
• connection_lock — the lock that serializes access to login_sent, login_received and transmit_path. no concurrent chaos allowed, we stan a mutex 🔒
• login_retries — the number of login retries currently done. we keep trying, bestie.
• login_work — the worker that sends ThunderboltIP login packets.
• connected_work — the worker that finalizes the ThunderboltIP connection setup and enables the DMA paths for high speed data transfers. it's the glow-up phase 🔥
• disconnect_work — the worker that handles tearing down the ThunderboltIP connection. sad but necessary 💀
• rx_hdr — a copy of the currently processed Rx frame, used when a network packet consists of multiple Thunderbolt frames. In host byte order. keep that in mind, it matters 🌟
• rx_ring — the software ring holding Rx frames. a whole little ring buffer of receives 🎀
• frame_id — the Frame ID use for the next Tx packet (if TBNET_MATCH_FRAGS_ID is supported in both ends). iykyk.
• tx_ring — the software ring holding Tx frames. matching ring, but for sends 🦋

---

🌈 SEE ALSO

• Kernel file ./drivers/net/thunderbolt/main.c struct
• thunderbolt_ip_frame_header(9)

---

lowkey a reminder: if TBNET_MATCH_FRAGS_ID isn't supported in both ends, that whole frame_id situation changes. both ends or it doesn't count, fr fr 🙈

---

and that's the page, bestie 💖 this lil' drop came from ./drivers/net/thunderbolt, dated October 2026, and it's filed under struct tbnet(9) — catch you in the kernel docs 🧚✨