<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">čt 29. 1. 2026 v 18:28 odesílatel Stephen Hemminger <<a href="mailto:stephen@networkplumber.org">stephen@networkplumber.org</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
How big is this beast?<br></blockquote><div><br></div><div>Heh, I am not sure if this was rhetorical or an actual technical question, but to answer, pahole reports it as 26,400 bytes big.</div><div>Previously, it was sized similarly (25,884 B), it was just spread out over many globally defined arrays.</div><div>The ~500 byte increase comes from new *_cache arrays (raw_encap_conf_cache, raw_decap_conf_cache, etc.).<br>In the original testpmd, external code accessed global arrays directly (e.g., raw_encap_confs[idx].data). The library provides accessor APIs like rte_flow_parser_raw_encap_conf_get() that return const struct rte_flow_action_raw_encap *. Since this API returns a pointer to a properly-typed action struct (not just raw data), the library needs storage for these structs.</div></div></div>