STRUCT XFRM_IPTFS_DATA(9)
π¦ struct xfrm_iptfs_data(9) π¦
okay so this is a page from the Kernel API Manual (section 9, bestie, kernel API land) and honestly? it's giving "the blueprint for one IPTFS tunnel's whole personality." buckle up π
β¨ NAME β¨
struct xfrm_iptfs_data β mode specific xfrm state. literally what it says on the tin: all the state that only makes sense for this one xfrm mode. no cap π
πΈ SYNOPSIS πΈ
struct xfrm_iptfs_data {
struct xfrm_iptfs_config cfg;
struct xfrm_state *x;
struct sk_buff_head queue;
u32 queue_size;
u32 ecn_queue_size;
u64 init_delay_ns;
struct hrtimer iptfs_timer;
time64_t iptfs_settime;
u32 payload_mtu;
bool w_seq_set;
u64 w_wantseq;
struct skb_wseq *w_saved;
u32 w_savedlen;
spinlock_t drop_lock;
struct hrtimer drop_timer;
u64 drop_time_ns;
struct sk_buff *ra_newskb;
u64 ra_wantseq;
u8 ra_runt[6];
u8 ra_runtlen;
};
like, that's the whole struct, every field, nothing skipped, periodt π
π Members π
cfgβ the IPTFS tunnel config. the settings bestie πxβ the owning SA (xfrm_state). this struct's main character.queueβ queued user packets that are waiting to go out. the to-send pile β¨queue_sizeβ how many octets are sitting onqueue(that's the sum of the packet sizes). not a packet count, an octet count, ok? πecn_queue_sizeβ octets up there that carry the ECN mark.init_delay_nsβ nanoseconds to wait before sending the initial IPTFS packet. patience, gorgeous, patience πΈiptfs_timerβ the output timer.iptfs_settimeβ the time the output timer was set.payload_mtuβ max payload size.w_seq_setβtrueafter the first seq has been received.w_wantseqβ we're waiting for this seq number as the next one to process (in order, always in order, we love an in-order queen π).w_savedβ the saved buf array (that's the reorder window).w_savedlenβ the saved len (not the size, bestie β len.w_savedlen. not the size π)drop_lockβ lock protecting the reorder queue. door needs a lock, obviously π«Άdrop_timerβ timer for considering the next packet lost.drop_time_nsβ timer intervan in nanoseconds (that's the page's spelling, not mine, iykyk π).ra_newskbβ the new pkt being reassembled.ra_wantseqβ expected next sequence for reassembly.ra_runtβ last pkt bytes from the very end of the last skb. it'su8 ra_runt[6]fr fr.ra_runtlenβ size ofra_runt.
π₯ SEE ALSO π₯
kernel file ./net/xfrm/xfrm_iptfs.c plus this whole friend group:
IPTFS_DEFAULT_DROP_TIME_USECS(9), IPTFS_DEFAULT_REORDER_WINDOW(9), IPTFS_DEFAULT_INIT_DELAY_USECS(9), IPTFS_DEFAULT_MAX_QUEUE_SIZE(9), struct xfrm_iptfs_config(9), iptfs_alloc_skb(9), iptfs_skb_head_to_frag(9), struct iptfs_skb_frag_walk(9), iptfs_skb_prepare_frag_walk(9), iptfs_skb_can_add_frags(9), iptfs_skb_add_frags(9), iptfs_pskb_add_frags(9), iptfs_pskb_extract_seq(9), iptfs_input_save_runt(9), __iptfs_iphlen(9), __iptfs_iplen(9), iptfs_complete_inner_skb(9), iptfs_reassem_abort(9), iptfs_reassem_done(9), iptfs_reassem_cont(9), iptfs_input_ordered(9), iptfs_drop_timer(9), iptfs_input(9), iptfs_enqueue(9), iptfs_copy_create_frag(9), iptfs_copy_create_frags(9), iptfs_first_skb(9), iptfs_encap_add_ipv4(9), iptfs_encap_add_ipv6(9), iptfs_prepare_output(9), __iptfs_get_inner_mtu(9), iptfs_get_inner_mtu(9), iptfs_user_init(9)
ngl every single one of those is a real thing you can look up, i'm not making them up, that would be so not slay of me π π
okay bye bestie, go read the source, it's iconic πβ
β from ./net/xfrm, dated October 2026. catch you in the kernel tree, mwah ππ§π
π¦ 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