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

[David Marchand]

Hello Venky, Anatoly,

On Fri, May 2, 2014 at 11:05 AM, Venkatesan, Venky <
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] On Behalf Of Burakov, Anatoly
> Sent: Friday, May 02, 2014 1:54 AM
> To: Burakov, Anatoly; David Marchand; 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