On 2/19/2026 8:08 PM, Stephen Hemminger wrote:
On Thu, 19 Feb 2026 16:22:43 +0000
Anatoly Burakov <[email protected]> wrote:
This patchset is an assortment of cleanups for ixgbe, i40e, iavf, and ice PMD.
AI review had some observations here:
Thanks Stephen!
Patch 20/27: net/iavf: avoid rte malloc in MAC address operations
in_args_size is always sizeof(list_req) (full 64-entry struct) regardless of
how many addresses are populated. The old code computed an exact-fit length.
Probably harmless since num_elements governs PF-side parsing, but worth
verifying.
This is intentional.
Patch 21/27: net/iavf: avoid rte malloc in IPsec operations
Pre-existing: iavf_ipsec_crypto_status_get() response struct uses struct
virtchnl_ipsec_cap but the function reads ipsec_status. The old code had the
same mismatch. Since you're refactoring this function, consider fixing the
response type to struct virtchnl_ipsec_status.
Since this is a pre-existing bug, we need to fix it and backport it
separately. Good find!
Patch 23/27: net/iavf: avoid rte malloc in irq map config
iavf_config_irq_map_lv_chunk(): double-offset bug. The loop runs for (i = chunk_start; i
< chunk_end; i++) but then indexes map_info->qv_maps[i] (should be [i -
chunk_start]) and vf->qv_map[chunk_start + i] (should be [i]). For the second chunk,
this writes past the local array and reads the wrong qv_map entries.
Good catch, will fix.
iavf_config_irq_map(): the num_vectors counting via if (vmi > max_vmi) only works
if vector IDs are assigned in monotonically increasing order across the queue
iteration. If not (e.g., round-robin where a lower vmi appears after a higher one),
the count will be too low. The old code simply used vf->nb_msix which is always
correct.
That is how it happens. The reason I changed it in the first place is
because *technically* there is no "max value" we can use here that would
be suitable to use because nb_msix comes from VF mailbox. We do,
however, know that vector ID's *are* assigned monotonically and in a
round-robin fashion, and in fact code comments indicate that this is the
assumption.
--
Thanks,
Anatoly
