STRUCT UDP_TUNNEL_NIC_INFO(9)
πΈ NAME πΈ
struct udp_tunnel_nic_info β the driver-side tea on UDP tunnel offload info π
(straight out of the Kernel API Manual, bestie, this is the real deal β¨)
β¨ SYNOPSIS β¨
struct udp_tunnel_nic_info {
int (*set_port)(struct net_device *dev, unsigned int table, unsigned int entry, struct udp_tunnel_info *ti);
int (*unset_port)(struct net_device *dev, unsigned int table, unsigned int entry, struct udp_tunnel_info *ti);
int (*sync_table)(struct net_device *dev, unsigned int table);
struct udp_tunnel_nic_shared *shared;
unsigned int flags;
struct udp_tunnel_nic_table_info {
unsigned int n_entries;
unsigned int tunnel_types;
} tables[UDP_TUNNEL_NIC_MAX_TABLES];
};
π MEMBERS π
okay so here's the whole cast, no skips, iykyk π
set_portβ the callback that adds a new port π«Άunset_portβ the callback that removes a port πsync_tableβ the callback that syncs the entire port table all at once, one big slay π₯sharedβ a reference to device global state, and it's optional (so lowkey you can skip it) πflagsβ device flags, and they come fromenum udp_tunnel_nic_info_flagsβtablesβ the UDP port tables this device has πtables.n_entriesβ how many entries live in this table, literally the count πtables.tunnel_typesβ which types of tunnels this table accepts, the vibe check of tunnels π
π DESCRIPTION π
so the way this works: drivers are expected to provide either set_port and unset_port callbacks or the sync_table callback. like, pick a lane bestie. and heads up β callbacks are invoked with the rtnl lock held π
now, devices which (misguidedly π) share the UDP tunnel port table across multiple netdevs should allocate an instance of struct udp_tunnel_nic_shared and point shared at it. and the rule is: there must never be more than UDP_TUNNEL_NIC_MAX_SHARING_DEVICES devices sharing a table. that's the limit, periodt π
β οΈ Known limitations β οΈ
- UDP tunnel port notifications are fundamentally best-effort β it is likely the driver will both see skbs which use a UDP tunnel port, while not being a tunneled skb, and tunnel skbs from other ports π so drivers should only use these ports for non-critical RX-side offloads, e.g. the checksum offload. non-critical only, bestie, don't get cute with it π
- none of the devices care about the socket family at present, so we don't track it. please extend this code if you care π«Ά (like, if that's your thing, go off π)
π¦ SEE ALSO π¦
Kernel file ./include/net/udp_tunnel.h and udp_tunnel_nic_reset_ntf(9) β go read those next, they ate π
β¨
and that's a wrap, bestie π this page lives in ./include/net, dated October 2026, and it's struct udp_tunnel_nic_info(9) in all its main character glory β go off, you understood the assignment ππΈπ¦
π¦ 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