STRUCT ADF_GEN6_TL_DEVICE_DATA_REGS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– struct adf_gen6_tl_device_data_regs(9) πŸ’–

okay bestie, welcome to the Kernel API Manual β€” this one's a struct page and honestly it's kind of a baddie. So like, struct adf_gen6_tl_device_data_regs is the place where device telemetry counter values live, and the device just keeps dropping fresh values in there periodically. It's giving "constantly updating group chat" energy fr fr. 🫢


✨ SYNOPSIS ✨

no cap, here's the whole thing, character for character:

struct adf_gen6_tl_device_data_regs {
    __u64 reg_tl_rd_lat_acc;
    __u64 reg_tl_gp_lat_acc;
    __u64 reg_tl_at_page_req_lat_acc;
    __u64 reg_tl_at_trans_lat_acc;
    __u64 reg_tl_re_acc;
    __u32 reg_tl_prt_trans_cnt;
    __u32 reg_tl_rd_lat_max;
    __u32 reg_tl_rd_cmpl_cnt;
    __u32 reg_tl_gp_lat_max;
    __u32 reg_tl_ae_put_cnt;
    __u32 reg_tl_bw_in;
    __u32 reg_tl_bw_out;
    __u32 reg_tl_at_page_req_cnt;
    __u32 reg_tl_at_trans_lat_cnt;
    __u32 reg_tl_at_max_utlb_used;
    __u32 reg_tl_re_cnt;
    __u32 reserved;
    struct adf_gen6_tl_slice_data_regs ath_slices[MAX_ATH_SL_COUNT];
    struct adf_gen6_tl_slice_data_regs cnv_slices[MAX_CNV_SL_COUNT];
    struct adf_gen6_tl_slice_data_regs dcprz_slices[MAX_DCPRZ_SL_COUNT];
    struct adf_gen6_tl_slice_data_regs pke_slices[MAX_PKE_SL_COUNT];
    struct adf_gen6_tl_slice_data_regs ucs_slices[MAX_UCS_SL_COUNT];
    struct adf_gen6_tl_slice_data_regs wat_slices[MAX_WAT_SL_COUNT];
    struct adf_gen6_tl_slice_data_regs wcp_slices[MAX_WCP_SL_COUNT];
    struct adf_gen6_tl_cmdq_data_regs ath_cmdq[MAX_ATH_CMDQ_COUNT];
    struct adf_gen6_tl_cmdq_data_regs cnv_cmdq[MAX_CNV_CMDQ_COUNT];
    struct adf_gen6_tl_cmdq_data_regs dcprz_cmdq[MAX_DCPRZ_CMDQ_COUNT];
    struct adf_gen6_tl_cmdq_data_regs pke_cmdq[MAX_PKE_CMDQ_COUNT];
    struct adf_gen6_tl_cmdq_data_regs ucs_cmdq[MAX_UCS_CMDQ_COUNT];
    struct adf_gen6_tl_cmdq_data_regs wat_cmdq[MAX_WAT_CMDQ_COUNT];
    struct adf_gen6_tl_cmdq_data_regs wcp_cmdq[MAX_WCP_CMDQ_COUNT];
 };

πŸŽ€ Members πŸŽ€

okay so, field by field, let's get into it πŸ’…

  • reg_tl_rd_lat_acc β€” the read latency accumulator, just collecting read-latency vibes 🌸
  • reg_tl_gp_lat_acc β€” "get to put" latency accumulator. yes that's the actual name, iykyk ✨
  • reg_tl_at_page_req_lat_acc β€” AT/DevTLB page request latency accumulator πŸ¦‹
  • reg_tl_at_trans_lat_acc β€” DevTLB transaction latency accumulator, stacking up those samples 🫢
  • reg_tl_re_acc β€” accumulated ring empty time. rings get empty, we keep track 😌
  • reg_tl_prt_trans_cnt β€” PCIe partial transactions, counted πŸ‘‘
  • reg_tl_rd_lat_max β€” the maximum logged read latency, the record-holder πŸ”₯
  • reg_tl_rd_cmpl_cnt β€” read requests completed count, slay βœ…
  • reg_tl_gp_lat_max β€” maximum logged get to put latency, the peak πŸ’€
  • reg_tl_ae_put_cnt β€” Accelerator Engine put counts across all rings. all of them, periodt πŸŒ€
  • reg_tl_bw_in β€” PCIe write bandwidth 🌈
  • reg_tl_bw_out β€” PCIe read bandwidth 🌈
  • reg_tl_at_page_req_cnt β€” DevTLB page requests count πŸ“
  • reg_tl_at_trans_lat_cnt β€” DevTLB transaction latency samples count 🧚
  • reg_tl_at_max_utlb_used β€” maximum uTLB used, the high score πŸ’œ
  • reg_tl_re_cnt β€” ring empty time samples count ⭐
  • reserved β€” reserved. it's reserved. that's it. that's the whole tea πŸ™ˆ

πŸ¦‹ the slice arrays πŸ¦‹

each of these is an array of utilization registers, one per slice, maxed out by their matching count macro β€” no invented numbers here bestie, the macros speak for themselves:

  • ath_slices β€” array of Authentication slices utilization registers
  • cnv_slices β€” array of Compression slices utilization registers
  • dcprz_slices β€” array of Decompression slices utilization registers
  • pke_slices β€” array of PKE slices utilization registers
  • ucs_slices β€” array of UCS slices utilization registers
  • wat_slices β€” array of Wireless Authentication slices utilization registers
  • wcp_slices β€” array of Wireless Cipher slices utilization registers

πŸ’œ the cmdq arrays πŸ’œ

same deal but for cmdq telemetry registers:

  • ath_cmdq β€” array of Authentication cmdq telemetry registers
  • cnv_cmdq β€” array of Compression cmdq telemetry registers
  • dcprz_cmdq β€” array of Decomopression cmdq telemetry registers (yes it's spelled Decomopression in the original and i'm not touching it, that's a heritage typo 🫢)
  • pke_cmdq β€” array of PKE cmdq telemetry registers
  • ucs_cmdq β€” array of UCS cmdq telemetry registers
  • wat_cmdq β€” array of Wireless Authentication cmdq telemetry registers
  • wcp_cmdq β€” array of Wireless Cipher cmdq telemetry registers

🌈 SEE ALSO 🌈

all of these live in the kernel file ./drivers/crypto/intel/qat/qat_common/adf_gen6_tl.h β€” go read the whole family, they're all iconic:

  • struct adf_gen6_tl_slice_data_regs(9)
  • struct adf_gen6_tl_cmdq_data_regs(9)
  • struct adf_gen6_tl_ring_pair_data_regs(9)
  • struct adf_gen6_tl_layout(9)

ok that's the whole page, nothing skipped, nothing invented πŸ’–

and for the sign-off: this cutie comes from ./drivers/crypto/intel/qat/qat..., dated October 2026, and yeah the title up top really is struct adf_...ce_data_regs(9) β€” shortened by the manpage tooling, not by me. bye bestie, go read your telemetry πŸ’…βœ¨πŸŽ€

πŸ“¦ where this page comes from