STRUCT NET_SHAPER_OPS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… NAME πŸ’…

struct net_shaper_ops β€” the ops that do stuff to your device's H/W shapers πŸŽ€

(okay so this whole page lives in the Kernel API Manual, and we're talking about struct net_shaper_ops β€” buckle up bestie ✨)


✨ SYNOPSIS ✨

struct net_shaper_ops {
    int (*group)(struct net_shaper_binding *binding, int leaves_count,
const struct net_shaper *leaves, const struct net_shaper *node, struct
netlink_ext_ack *extack);
    int (*set)(struct net_shaper_binding *binding, const struct
net_shaper *shaper, struct netlink_ext_ack *extack);
    int (*delete)(struct net_shaper_binding *binding, const struct
net_shaper_handle *handle, struct netlink_ext_ack *extack);
    void (*capabilities)(struct net_shaper_binding *binding, enum
net_shaper_scope scope, unsigned long *cap);
 };

🫢 Members 🫢

🧚 group β€” create a scheduling group or add leaves

Nest the leaves shapers identified under the node shaper. All the shapers belong to the device specified by binding. The leaves array's size is specified by leaves_count.

node and leaves may or may not already exist (peep the "Implicit creation" note πŸ‘€). If node already exists, the leaves should be added to its children. In that case, the leaves array only holds new/modified leaves β€” not the full list. iykyk.

Re-parenting leaves is implemented by a group call on a new parent. There's no explicit call to remove the children from the old parent. It's giving "no awkward breakup conversation" energy πŸ’€

πŸ¦‹ set β€” Updates the specified shaper

Updates or creates the shaper on the device specified by binding. That's it, that's the vibe πŸ’–

🌸 delete β€” Removes the specified shaper

Removes the shaper configuration as identified by the given handle on the device specified by binding, restoring the default behavior.

Note that a delete call on a NET_SHAPER_SCOPE_QUEUE shaper also implicitly removes the associated queue from the scheduling hierarchy. The driver must take care of that step. delete calls on NET_SHAPER_SCOPE_NODE should not require any implicit re-parenting in the driver, because core will re-parent the leaves first, before deleting the SCOPE_NODE shaper. bestie the core did the homework for you, don't redo it πŸ™ˆ

πŸ‘‘ capabilities β€” get the shaper features supported by the device

Fills the bitmask cap with the supported capabilities for the specified scope and device specified by binding. It's literally a vibe check for your hardware ✨


🌈 Description 🌈

The operations apply to either net_device and devlink objects. The initial shaping configuration at device initialization is empty: it does not constrain the rate in any way. The network core keeps track of the applied user-configuration in the net_device or devlink structure. The operations are serialized via a per device lock. πŸ”’

Device not supporting any kind of nesting should not provide the group operation. no nesting? no group op. simple as that πŸŽ€

Each shaper is uniquely identified within the device with a 'handle' comprising the shaper scope and a scope-specific id.

⚑ Driver ops vs uAPI ⚑

Members of the driver ops mirror the Netlink uAPI but driver calls do not map 1:1 to user calls. Drivers need to be careful when assuming that calls disallowed at the uAPI level will never be made at the driver level. The shaper core performs automatic reparenting and cleanup, generating additional calls. Notably:

  • group calls in the driver facing API may have nodes as leaves (user is only allowed to construct groups with queues as leaves)
  • group calls may update leaf's parent if the parent is about to be removed (re-parenting nodes explicitly is not supported in the uAPI)
🚨 fr fr read that again β€” the driver-facing side is spicy and the core will surprise you. Not me warning you twice. πŸ’€

🐣 Implicit creation 🐣

Shapers are created implicitly, meaning that set and group operations are called both for existing and new shapers. The driver has to infer whether the operation is an update or a creation by tracking the handles. Removal of shapers is explicit and done with a delete call.

The set operation implicitly creates NET_SHAPER_SCOPE_NETDEV and NET_SHAPER_SCOPE_QUEUE shapers. The group operation implicitly creates NET_SHAPER_SCOPE_NETDEV and NET_SHAPER_SCOPE_NODE shapers (the group shaper itself), as well as NET_SHAPER_SCOPE_QUEUE shapers (leaves). slay πŸ’…


🌟 SEE ALSO 🌟

  • Kernel file ./include/net/net_shaper.h
  • struct net_shaper(9)

okay that's the whole page, go forth and shape your shapers πŸ¦‹βœ¨

sign-off szn: this iconic little doc comes from ./include/net, dated October 2026, and it's struct net_shaper_ops(9) in the Kernel API Manual β€” mwah πŸ’–πŸŽ€

πŸ“¦ where this page comes from