STRUCT NFT_SET_OPS(9)
π struct nft_set_ops(9) π
Okay bestie, so this is from the Linux kernel API manual β it's literally the struct that defines all the operations for nf_tables sets. And yes, it's giving big "the backend of your firewall" energy. The source file is ./include/net/netfilter and it's dated October 2026, so it's fresh. Let's get into it π
β¨ NAME β¨
struct nft_set_ops β nf_tables set operations. The whole vibe is: this struct holds the function pointers that tell the kernel how to do stuff with a set (lookup, insert, delete, etc.). Main character energy for the entire set subsystem, fr fr πΈ
π SYNOPSIS π
struct nft_set_ops {
const struct nft_set_ext * (*lookup)(const struct net *net,
const struct nft_set *set, const u32 *key);
const struct nft_set_ext * (*update)(struct nft_set *set, const
u32 *key, const struct nft_expr *expr, struct nft_regs *regs);
bool (*delete)(const struct nft_set *set, const u32 *key);
int (*insert)(const struct net *net, const struct nft_set *set,
const struct nft_set_elem *elem, struct nft_elem_priv **priv);
void (*activate)(const struct net *net, const struct nft_set *set,
struct nft_elem_priv *elem_priv);
struct nft_elem_priv * (*deactivate)(const struct net *net,
const struct nft_set *set, const struct nft_set_elem *elem);
void (*flush)(const struct net *net, const struct nft_set *set,
struct nft_elem_priv *priv);
void (*remove)(const struct net *net, const struct nft_set *set,
struct nft_elem_priv *elem_priv);
void (*walk)(const struct nft_ctx *ctx, struct nft_set *set, struct
nft_set_iter *iter);
struct nft_elem_priv * (*get)(const struct net *net, const
struct nft_set *set, const struct nft_set_elem *elem, unsigned int
flags);
u32 (*ksize)(u32 size);
u32 (*usize)(u32 size);
u32 (*adjust_maxsize)(const struct nft_set *set);
void (*commit)(struct nft_set *set);
void (*abort)(const struct nft_set *set);
u64 (*privsize)(const struct nlattr * const nla[], const struct
nft_set_desc *desc);
bool (*estimate)(const struct nft_set_desc *desc, u32 features,
struct nft_set_estimate *est);
int (*init)(const struct nft_set *set, const struct nft_set_desc
*desc, const struct nlattr * const nla[]);
void (*destroy)(const struct nft_ctx *ctx, const struct nft_set
*set);
void (*gc_init)(const struct nft_set *set);
bool abort_skip_removal;
unsigned int elemsize;
};
π MEMBERS π
Okay so each of these is a function pointer (or a field) that does a specific job. Let's break it down one by one, no skipping, periodt π
lookupβ literally just looks up an element inside the set. Slay, that's it.updateβ updates an element if it already exists, or adds it if it doesn't. It's giving "fix it or make it" energy π₯deleteβ deletes an element. Bye bestie πinsertβ inserts a brand-new element into the set. Fresh meat, no cap.activateβ activates a new element in the next generation. It's like making it official for the next round πdeactivateβ looks up an element and deactivates it in the next generation. Lowkey the opposite of activate, you get me.flushβ deactivates an element in the next generation. It's giving "clean slate" vibes β¨removeβ removes an element from the set entirely. Gone, periodt.walkβ iterates over all the set elements. Like scrolling through your fyp but for kernel sets πgetβ gets set elements. Just fetch, bestie.ksizeβ kernel set size. The size from the kernel's perspective, iykyk.usizeβ userspace set size. The size from userspace's perspective.adjust_maxsizeβ delta to adjust the maximum set size. It's the little tweak that makes the limit just right πcommitβ commits set elements. You know, making it permanent and official πabortβ aborts set elements. Ctrl+Z energy.privsizeβ function to return the size of set private data. How much private data space does this set need? This tells you.estimateβ estimates the required memory size and the lookup complexity class. It's giving "how much RAM will this eat and how fast is it" π§initβ initializes the private data of a new set instance. Fresh start, no cap.destroyβ destroys the private data of a set instance. RIP in peace πgc_initβ initializes garbage collection. Yes, even the kernel needs to take the trash out ποΈabort_skip_removalβ skips removal of elements from the abort path. It's a bool, lowkey just says "hey, don't remove these on abort."elemsizeβ element private size. An unsigned int, just chillin'.
β¨ DESCRIPTION β¨
Okay so real talk: the operations lookup, update, and delete have simpler interfaces, are faster, and currently only used in the packet path. That's the hot path, the main character part of the networking stack π
All the rest? They're slower, control plane functions. Still iconic, but they're not in the fast lane. It's giving "backstage vs. on stage" energy π
Warning bestie: the Description says these are the slower ones β so don't put them in your packet-processing hot loop unless you want your network to feel like it's buffering on 2G π No cap.
π SEE ALSO π
Okay, so the original lists a bunch of related structs from ./include/net/netfilter/nf_tables.h. Like, it's a whole friend group. Here they all are, exactly as listed, bestie:
nft_verdict(9), nft_regs(9), nft_ctx(9), nft_userdata(9), nft_set_elem(9), enum nft_iter_type(9), nft_set_desc(9), enum nft_set_class(9), nft_set_estimate(9), nft_expr(9), nft_set_type(9), nft_set(9), nft_set_binding(9), enum nft_set_extensions(9), nft_set_ext_type(9), nft_set_ext_tmpl(9), nft_set_ext(9), nft_expr_type(9), nft_expr_ops(9), nft_rule(9), nft_chain_validate_state(9), nft_chain(9), nft_chain_type(9), nft_base_chain(9), nft_table(9), nft_object_hash_key(9), nft_object(9), nft_object_type(9), nft_object_ops(9), nft_flowtable(9), nft_traceinfo(9), nft_trans(9), nft_trans_hook(9), nft_trans_binding(9)
And that's the whole manual page, bestie! π«Ά So like, this page comes from the kernel source at ./include/net/netfilter and it's dated October 2026. Go forth and slay your nf_tables sets πβ¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms