[PATCH v4 20/27] net/iavf: avoid rte malloc in MAC address operations

[Burakov, Anatoly]

On 2/19/2026 10:32 AM, Bruce Richardson wrote:
> On Thu, Feb 19, 2026 at 09:29:40AM +0000, Bruce Richardson wrote:
>> On Thu, Feb 19, 2026 at 10:22:24AM +0100, Burakov, Anatoly wrote:
>>> On 2/16/2026 6:27 PM, Bruce Richardson wrote:
>>>> On Fri, Feb 13, 2026 at 10:26:31AM +0000, Anatoly Burakov wrote:
>>>>> Currently, when adding or deleting MAC addresses, we are using
>>>>> rte_zmalloc followed by an immediate rte_free. This is not needed as this
>>>>> memory is not being stored anywhere, so replace it with regular
>>>>> malloc/free.
>>>>>
>>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>
>>>>> ---
>>>>>    drivers/net/intel/iavf/iavf_vchnl.c | 4 ++--
>>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c b/drivers/net/intel/iavf/iavf_vchnl.c
>>>>> index 55986ef909..19dce17612 100644
>>>>> --- a/drivers/net/intel/iavf/iavf_vchnl.c
>>>>> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
>>>>> @@ -1402,7 +1402,7 @@ iavf_add_del_all_mac_addr(struct iavf_adapter *adapter, bool add)
>>>>>    			}
>>>>>    		}
>>>>> -		list = rte_zmalloc("iavf_del_mac_buffer", len, 0);
>>>>> +		list = calloc(1, len);
>>>>
>>>> Given the loop above has a threshold set for IAVF_AQ_BUF_SZ, maybe a static
>>>> buffer of that fixed size might be better?
>>>
>>> That size is 4 kilobytes, so I agree that we can use one buffer rather than
>>> constantly allocating/deallocating things, it'll still have to be
>>> dynamically allocated.
>>>
>> I still would use a stack variable myself. 4k really isn't that big
>> nowadays.
>>
> 4k is also PATH_MAX, and we use stack arrays of PATH_MAX size everywhere in
> DPDK, so I think we can assume that it's an ok size to use as a stack
> variable.
> 
> /Bruce

Ack. While attempting to figure out this code I just uncovered a whole 
bunch of other places where we could replace things with a stack 
allocation :/

(not submitting them in this patchset, but there's gonna be more rework 
like this in the future)

-- 
Thanks,
Anatoly