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

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

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@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.

> 
> Also, that check itself seems a little off, since it allows buffers greater
> than the size, rather than ignoring the length of the address that pushes
> it over the limit.

Yes, this seems like an opportunity for a bugfix. I'll submit it separately.

> 
>>   		if (!list) {
>>   			PMD_DRV_LOG(ERR, "fail to allocate memory");
>>   			return;
>> @@ -1434,7 +1434,7 @@ iavf_add_del_all_mac_addr(struct iavf_adapter *adapter, bool add)
>>   			PMD_DRV_LOG(ERR, "fail to execute command %s",
>>   				    add ? "OP_ADD_ETHER_ADDRESS" :
>>   				    "OP_DEL_ETHER_ADDRESS");
>> -		rte_free(list);
>> +		free(list);
>>   		begin = next_begin;
>>   	} while (begin < IAVF_NUM_MACADDR_MAX);
>>   }
>> -- 
>> 2.47.3
>>


-- 
Thanks,
Anatoly