STRUCT EF4_TX_QUEUE(9)

💖 struct ef4_tx_queue(9) 💖

okay so bestie, welcome to the Kernel API Manual page for struct ef4_tx_queue — aka "An Efx TX queue" ✨ this is the whole glow-up of one TX queue, every field laid out, and honestly it's giving main character energy for the falcon driver 🦋

---

🎀 NAME 🎀

struct ef4_tx_queue — An Efx TX queue 👑

---

✨ SYNOPSIS ✨

here's the whole struct, copied exactly, don't touch a single character bestie 💅

struct ef4_tx_queue {
    struct ef4_nic *efx;
    unsigned queue;
    struct ef4_channel *channel;
    struct netdev_queue *core_txq;
    struct ef4_tx_buffer *buffer;
    struct ef4_buffer *cb_page;
    struct ef4_special_buffer txd;
    unsigned int ptr_mask;
    bool initialised;
    unsigned int tx_min_size;
    int (*handle_tso)(struct ef4_tx_queue*, struct sk_buff*, bool *);
    unsigned int read_count;
    unsigned int old_write_count;
    unsigned int merge_events;
    unsigned int bytes_compl;
    unsigned int pkts_compl;
    unsigned int insert_count;
    unsigned int write_count;
    unsigned int old_read_count;
    unsigned int pushes;
    bool xmit_more_available;
    unsigned int cb_packets;
    unsigned long tx_packets;
    unsigned int empty_read_count;
  #define EF4_EMPTY_COUNT_VALID 0x80000000;
    atomic_t flush_outstanding;
};

---

🌸 Members 🌸

• efx — the Efx NIC this queue is attached to 🫶
• queue — the DMA queue number 🔢
• channel — the associated channel 💫
• core_txq — the networking core TX queue structure, like the netdev's own bookkeeping for this queue 📓
• buffer — the software buffer ring 🧚
• cb_page — array of pages of copy buffers. it gets carved up according to EF4_TX_CB_ORDER into EF4_TX_CB_SIZE-sized chunks 🍰 (yes, sliced like a cake, no cap)
• txd — the hardware descriptor ring 💀 the real one
• ptr_mask — the size of the ring minus 1. classic mask move, iconic
• initialised — has the hardware queue been initialised? 🤔 yes/no vibes only
• tx_min_size — minimum transmit size for this queue. it depends on HW, so don't come for her 🫶
• read_count — current read pointer. this is the number of buffers that have been removed from both rings 👀
• old_write_count — the value of write_count when last checked. this is here for performance reasons. the xmit path will only get the up-to-date value of write_count if this variable indicates that the queue is empty. this is to avoid cache-line ping-pong between the xmit path and the completion path 🏓 (yes literally ping-pong, that's the actual term, iykyk)
• merge_events — number of TX merged completion events 🔥
• insert_count — current insert pointer. this is the number of buffers that have been added to the software ring 🧺
• write_count — current write pointer. this is the number of buffers that have been added to the hardware ring 💾
• old_read_count — the value of read_count when last checked. this is here for performance reasons. the xmit path will only get the up-to-date value of read_count if this variable indicates that the queue is full. this is to avoid cache-line ping-pong between the xmit path and the completion path 🏓 again. same energy, opposite condition, obsessed
• pushes — number of times the TX push feature has been used 👟
• xmit_more_available — are any packets waiting to be pushed to the NIC? 📬
• cb_packets — number of times the TX copybreak feature has been used 📦
• empty_read_count — if the completion path has seen the queue as empty and the transmission path has not yet checked this, then it's the value of read_count bitwise-added to EF4_EMPTY_COUNT_VALID; otherwise 0 🫠

ngl, the struct also carries handle_tso, bytes_compl, pkts_compl and flush_outstanding — they're up there in the synopsis fr fr, this Members list just doesn't say anything about them. no cap, that's literally all the page gives you 💀

---

💜 Description 💜

so what actually is this thing? it's a ring buffer of TX fragments 🌀 periodt.

since the TX completion path always executes on the same CPU, but the xmit path can operate on different CPUs, performance gets increased by ensuring that the completion path and the xmit path operate on different cache lines 🧠✨ this is particularly important if the xmit path is always executing on one CPU which is different from the completion path. like, highkey crucial 🙏

there's also a cache line for members which are read but not written on the fast path 👑 everyone gets their own space, no crowding, we love boundaries.

---

🦋 SEE ALSO 🦋

• kernel file ./drivers/net/ethernet/sfc/falcon/net_driver.h
• struct ef4_buffer(9)
• struct ef4_special_buffer(9)
• struct ef4_tx_buffer(9)
• struct ef4_rx_buffer(9)
• struct ef4_rx_page_state(9)
• struct ef4_rx_queue(9)
• struct ef4_channel(9)
• struct ef4_msi_context(9)
• struct ef4_channel_type(9)
• struct ef4_link_state(9)
• struct ef4_phy_operations(9)
• enum ef4_phy_mode(9)
• struct ef4_hw_stat_desc(9)
• struct ef4_nic(9)
• struct ef4_nic_type(9)

---

and that's the whole page bestie, go forth and read those TX fragments 💖

this icon was brought to you by ./drivers/net/ethernet/sfc/falcon, dated October 2026, and it says struct ef4_tx_queue(9) at the bottom like a little signature 🎀 mwah 💋