[PATCH v4 20/27] net/iavf: avoid rte malloc in MAC address operations
Bruce Richardson
bruce.richardson at intel.com
Thu Feb 19 10:29:40 CET 2026
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.
/Bruce
More information about the dev
mailing list