STRUCT ADF_RL_SLA_INPUT_DATA(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’œ struct adf_rl_sla_input_data(9) β€” the Kernel API Manual, but make it make sense

okay so bestie, welcome to the Kernel API Manual ✨ and today's main character is struct adf_rl_sla_input_data, which is literally the ratelimiting user input data structure πŸŽ€ yes that's its whole NAME, and yes it ate.


πŸ¦‹ SYNOPSIS πŸ¦‹

here's the shape of it, no cap, copy it exactly:

struct adf_rl_sla_input_data {
    u64 rp_mask;
    int sla_id;
    int parent_id;
    unsigned int cir;
    unsigned int pir;
    enum rl_node_type type;
    enum adf_base_services srv;
 };

🌸 Members 🌸

so these are the fields, and i'm gonna be so fr with you about each one:

  • rp_mask β€” a 64 bit bitmask of ring pair IDs that are gonna get assigned to the SLA πŸ’… like, for example 0x5 means RP0 and RP2 get assigned, and 0xA005 means RP0,2,13,15 get assigned. it's giving hex homework but honestly iconic.
  • sla_id β€” the ID of the current SLA, for the operations update, rm, and get πŸ”₯ and for the add operation? this field literally gets updated with the ID of the newly added SLA. not me becoming a different value mid-operation 😭
  • parent_id β€” the ID of the SLA that the current one should be assigned to 🫢 set it to -1 to refer to the default parent. easy.
  • cir β€” Committed information rate πŸ’– the rate that's guaranteed to be achieved. the input value is expressed in permille scale, i.e. 1000 refers to the maximum device throughput for a selected service. promise, guaranteed, on god.
  • pir β€” Peak information rate ⭐ the maximum rate available that the SLA can achieve. also expressed in permille scale, i.e. 1000 refers to the maximum device throughput for a selected service. the ceiling, the limit, the whole vibe.
  • type β€” the SLA type: root, cluster, node 🌈 pick your fighter.
  • srv β€” the service associated to the SLA: asym, sym dc 🧚 short names, big energy.

✨ Description ✨

so this structure is used to perform operations on an SLA πŸ’« and depending on which operation you're doing, some of the parameters just get ignored β€” literally not invited to the function, and that's fine.

here's the list of which parameters you should actually set for each operation, bestie, don't skip it:

  • add: all except sla_id
  • update: cir, pir, sla_id
  • rm: sla_id
  • rm_all: -
  • get: sla_id
  • get_capability_rem: srv, sla_id
🩷 quick vibe check: fill in the wrong fields and the kernel's just gonna be like 🧍 no thoughts head empty. match the operation to the fields, okay?

πŸŽ€ SEE ALSO πŸŽ€

go read these too, i'm obsessed:

  • Kernel file ./drivers/crypto/intel/qat/qat_common/adf_rl.h
  • struct adf_rl(9)
  • struct rl_sla(9)

and that's the whole page, periodt πŸ’… mwah. this one came from ./drivers/crypto/intel/qat/qat... and it's dated October 2026, and the header said struct adf_r...a_input_data(9) in case you were wondering β€” love that for us, talk later bestie πŸ«ΆπŸ’–

πŸ“¦ where this page comes from