STRUCT ETHTOOL_MM_STATE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ¦‹ struct ethtool_mm_state(9) β€” 802.3 MAC merge layer state

okay so first things first, this whole page lives in the Kernel API Manual section 9, and the function/struct we're stanning today is struct ethtool_mm_state, which is literally just the state of the 802.3 MAC merge layer. that's it, that's the vibe. she's a struct, she holds state, she's iconic πŸ’…


✨ SYNOPSIS ✨

struct ethtool_mm_state {
    u32 verify_time;
    u32 max_verify_time;
    enum ethtool_mm_verify_status verify_status;
    bool tx_enabled;
    bool tx_active;
    bool pmac_enabled;
    bool verify_enabled;
    u32 tx_min_frag_size;
    u32 rx_min_frag_size;
 };

like. look at her. nine fields, all baddies, no filler πŸŽ€


🌸 Members 🌸

bestie get comfy, we're going field by field, no skips, no cap.

  • verify_time β€” the wait time between verification attempts, in ms. per clause 30.14.1.6 aMACMergeVerifyTime. so like, how long you're gonna sit there before trying again ✨
  • max_verify_time β€” the biggest value that verify_time is ever allowed to take in set requests. it's giving "know your limits" πŸ’€
  • verify_status β€” the current state of the verification state machine of the MM layer, per clause 30.14.1.2 aMACMergeStatusVerify. main character energy fr.
  • tx_enabled β€” set if the MM layer is administratively enabled in the TX direction, per clause 30.14.1.3 aMACMergeEnableTx. admin said yes πŸ’–
  • tx_active β€” set if the MM layer is actually enabled in the TX direction, which is what makes FP possible, per 30.14.1.5 aMACMergeStatusTx. this one should be true if MM is enabled and the verification status is either verified or disabled. so like, enabled + (verified || disabled) = slay 🫢
  • pmac_enabled β€” set if the preemptible MAC is powered on and can receive preemptible packets and respond to verification frames. she's awake, she's responsive, she's booked and busy πŸ”₯
  • verify_enabled β€” set if the Verify function of the MM layer (the one that sends SMD-V verification requests) is administratively enabled, regardless of whether it's currently sitting in the ETHTOOL_MM_VERIFY_STATUS_DISABLED state or not, per clause 30.14.1.4 aMACMergeVerifyDisableTx β€” but using positive rather than negative logic, because we're being nice about it 🌈. also important: the device should always respond to received SMD-V requests as long as pmac_enabled is set. periodt.
  • tx_min_frag_size β€” the minimum size of non-final mPacket fragments that the link partner supports receiving, in octets. and here's the cute part: clause 30.14.1.7 aMACMergeAddFragSize expresses this in the range 0 to 3, which needs a translation to the size in octets via the formula 64 * (1 + addFragSize) - 4. but over here you can just specify a value in a continuous and unbounded range. no math trauma required 😭✨
  • rx_min_frag_size β€” the minimum size of non-final mPacket fragments that this device supports receiving, in octets. this is us. we support that πŸ“

πŸ‘‘ SEE ALSO πŸ‘‘

Kernel file ./include/linux/ethtool.h, plus the whole extended friend group:


and that's the whole page bestie πŸ’œ this one ships out of ./include/linux and the date on it is October 2026 β€” go read it again if you need to, i'll wait. mwah πŸŽ€βœ¨

πŸ“¦ where this page comes from