ice_flow_set_fld(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… ice_flow_set_fld(9) β€” like, the kernel API manual page, bestie

okay so this is ice_flow_set_fld from the Kernel API Manual, and it's genuinely one of those little functions that does So Much. sit down, grab a strawberry drink πŸ“, let's get into it.


✨ NAME ✨

ice_flow_set_fld β€” specifies locations of field from entry's input buffer πŸŽ€

like literally it tells the kernel where in the input buffer a field lives. that's the whole vibe.


🌸 SYNOPSIS 🌸

void ice_flow_set_fld (struct ice_flow_seg_info *seg , enum
ice_flow_field fld , u16 val_loc , u16 mask_loc , u16 last_loc , bool
range );

no cap, that's the exact signature. do not come for me about the line breaks, that's how it is.


πŸ¦‹ ARGUMENTS πŸ¦‹

  • seg β€” the packet segment that the field you're setting belongs to. it's giving "which section of the packet are we even talking about" πŸ’
  • fld β€” the field to be set. the actual main character here.
  • val_loc β€” if it's not ICE_FLOW_FLD_OFF_INVAL, this is the location of the value to match, pulled from the entry's input buffer.
  • mask_loc β€” if it's not ICE_FLOW_FLD_OFF_INVAL, this is the location of the mask value from the entry's input buffer.
  • last_loc β€” if it's not ICE_FLOW_FLD_OFF_INVAL, this is the location of the last/upper value from the entry's input buffer.
  • range β€” tells you whether the field being matched is meant to be in a range. yes/no, that kind of energy.
ok important: ICE_FLOW_FLD_OFF_INVAL is the "nope, nothing here" sentinel for val_loc, mask_loc and last_loc. if you see it, that location is not being used. periodt.

πŸ’– DESCRIPTION πŸ’–

so here's the tea β˜• β€” this function specifies the locations (in the form of byte offsets from the start of the input buffer for a flow entry) from where the value to match, the mask value, and the upper value can be extracted. 🫢

those locations then get stored in the flow profile. and later, when you're adding a flow entry associated with that flow profile, those same locations get used to quickly extract the values and create the content of a match entry. it's efficiency, it's icon energy, it's the whole point. πŸ”₯

⚠️ but listen β€” this function should only be used for fixed-size data structures. not a suggestion, bestie. fixed-size only.

🌈 SEE ALSO 🌈

kernel file ./drivers/net/ethernet/intel/ice/ice_flow.c β€” go read it, iykyk πŸ“–

and like, the entire extended universe of ice/rss functions (yes, all of them, i'm obsessed with how many there are):

ice_flow_val_hdrs(9), ice_flow_calc_seg_sz(9), ice_flow_proc_seg_hdrs(9), ice_flow_xtract_fld(9), ice_flow_xtract_raws(9), ice_flow_create_xtrct_seq(9), ice_flow_proc_segs(9), ice_flow_find_prof_conds(9), ice_flow_find_prof_id(9), ice_flow_rem_entry_sync(9), ice_flow_add_prof_sync(9), ice_flow_rem_prof_sync(9), ice_flow_assoc_prof(9), ice_flow_disassoc_prof(9), ice_flow_set_parser_prof(9), ice_flow_add_prof(9), ice_flow_rem_prof(9), ice_flow_add_entry(9), ice_flow_rem_entry(9), ice_flow_set_fld_ext(9), ice_flow_add_fld_raw(9), ice_flow_rem_vsi_prof(9), ice_flow_set_rss_seg_info(9), ice_rem_vsi_rss_list(9), ice_rem_vsi_rss_cfg(9), ice_get_rss_hdr_type(9), ice_rem_rss_list(9), ice_add_rss_list(9), ice_rss_config_xor_word(9), ice_rss_config_xor(9), ice_rss_set_symm(9), ice_rss_cfg_raw_symm(9), ice_rss_update_raw_symm(9), ice_add_rss_cfg_sync(9), ice_add_rss_cfg(9), ice_rem_rss_cfg_sync(9), ice_rem_rss_cfg(9), ice_add_avf_rss_cfg(9), ice_set_rss_cfg_symm(9), ice_replay_rss_cfg(9), ice_get_rss_cfg(9)


that's the whole page bestie, you ate it up πŸ’…

source path is ./drivers/net/ethernet/intel/ice and it's dated October 2026 β€” so yeah, this manual page is from the future and it's still fabulous. bye bestie, go set some flow fields πŸ§šβ€β™€οΈβœ¨

πŸ“¦ where this page comes from