[dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation

Venkatesan, Venky venky.venkatesan at intel.com
Wed May 7 16:56:46 CEST 2014


David,

Sorry for the late response. Yes, your suggestion would work. Let’s implement it …

Regards,
-Venky

From: David Marchand [mailto:david.marchand at 6wind.com]
Sent: Monday, May 05, 2014 2:26 AM
To: Venkatesan, Venky
Cc: Burakov, Anatoly; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation

Hello Venky, Anatoly,

On Fri, May 2, 2014 at 11:05 AM, Venkatesan, Venky <venky.venkatesan at intel.com<mailto:venky.venkatesan at intel.com>> wrote:
Agree with Anatoly - I would much rather not change legacy option behaviour that has existed for a while, especially when --socket-mem is available to do exactly what is needed.

-Venky

-----Original Message-----
From: dev [mailto:dev-bounces at dpdk.org<mailto:dev-bounces at dpdk.org>] On Behalf Of Burakov, Anatoly
Sent: Friday, May 02, 2014 1:54 AM
To: Burakov, Anatoly; David Marchand; dev at dpdk.org<mailto:dev at dpdk.org>
Subject: Re: [dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation

Sorry for spamming, but now that I think of it, I don't believe this change makes much sense. If the user wants memory on specific sockets, there's already --socket-mem option. If the user doesn't care, there's -m option, which gives the user memory from whatever sockets it is available. With this change applied, DPDK will fail when run with -m switch under certain circumstances (e.g. cores from socket 0 present in the coremask but no memory left on socket 0), which is quite the opposite of a simple "give me n megs, I don't care where it comes from" option -m is providing.

Actually, if we don't care where memory is allocated, we can at least try to have the more common setup work properly (i.e. spread memory allocations based on used cores).
I can see no usual setup where you want to use cores on a socket while having all memory on another socket but still expect performance to be good.

So here is another approach for Didier's patch.
We can try to spread memory on numa sockets, if this fails, then we default to previous behavior but leave a trace with a warning log "Could not spread memory on numa sockets".

What do you think about this ?


I would also take into account Anatoly's comments (multi line comments + ensure we won't try to get more memory than asked by user).

--
David Marchand


More information about the dev mailing list