David,

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

Regards,
-Venky

From: David Marchand [mailto:david.march...@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-boun...@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

Reply via email to