ovs_vport_fi...pcall_portid(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… ovs_vport_fi...pcall_portid β€” the kernel API manual, but make it make sense

okay so bestie, quick housekeeping: this whole glowing page lives in section 9 of the Kernel API Manual, and the vibe is ovs_vport_fi...pcall_portid(9) in case you were wondering what to type into man πŸ’–


✨ NAME ✨

ovs_vport_find_upcall_portid β€” literally just finds the upcall portid so it can send the upcall. that's it. that's the whole job. πŸŽ€


🌸 SYNOPSIS 🌸

u32 ovs_vport_find_upcall_portid (const struct vport *vport , struct
       sk_buff *skb );

yes it returns a u32, yes it takes two args, no we are not scared of it 🫢


πŸ¦‹ ARGUMENTS πŸ¦‹

  • vport β€” the vport that the missed packet came in on. like, the one that received it. that's your starting point, bestie.
  • skb β€” the skb that the missed packet was received in. yes, skb. the packet itself. you already knew that πŸ’…

πŸ‘‘ DESCRIPTION πŸ‘‘

so what actually happens? it uses skb_get_hash to pick which upcall portid gets the upcall. that's the selection process, that's the whole algorithm, no cap ✨

then it returns the portid of the target socket. main character return value energy.

🚨 real talk though: this must be called with rcu_read_lock. not "should", not "ideally", must. lock it before you call it or you're gonna have a bad time 😭

🌈 SEE ALSO 🌈

the kernel file is ./net/openvswitch/vport.c and honestly the whole friend group shows up here β€” go say hi:


okay that's the page!! this cutie is filed under ./net/openvswitch, stamped October 2026, and answers to the name ovs_vport_fi...pcall_portid(9) β€” go forth, lock your rcu, and slay πŸ’–πŸŽ€πŸ¦‹β­πŸ”₯

πŸ“¦ where this page comes from