[PATCH v4 20/27] net/iavf: avoid rte malloc in MAC address operations
Burakov, Anatoly
anatoly.burakov at intel.com
Thu Feb 19 10:22:24 CET 2026
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.
>
> 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
More information about the dev
mailing list