From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 25B30B0C0 for ; Tue, 6 May 2014 17:18:50 +0200 (CEST) Received: by mail-wg0-f41.google.com with SMTP id z12so3808392wgg.0 for ; Tue, 06 May 2014 08:18:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=YKKbTSJpqFjAmyY8/7qz1Q6hmh/LUYBFJM/XoVPOE7E=; b=B7kSnNi6PTTwBWPkfJuFh0ezA+lbC+0Wxbheq2PIlh+hWQsumtrvpSVyEBol/y3HKm l3BThmq9Blyg1CfZo1yH+5Gxcrq5fdtSs8jXTjpsTyK7V4200ND3z4OSq+jyApM9cCsf tNCZBjKQgkPrf6XRNIWRKjIHf9xYiNR9y6ikucVw5UAk68q265PgHTWlQEXvxiCapdoo rOUZ7phTuF4lDUk5vKF4mXQhOzEnBex7XcaXBsq7wPeL2DCBRcgeEY+tkyuZt8hR68rI 4ozWpDMlewWxCuhV/TdmaOfZSOMOaH2YmV2K2DhuMd0zALfYdBi3fOPJYISAWPBS6++j 1fhA== X-Gm-Message-State: ALoCoQnJ3JhUPr80oMqwsy8d0riD9FyvmSYeFdpq2/xbszF0ne7aaAiH/KrNlBm+jh6PX6C0il9M X-Received: by 10.180.198.48 with SMTP id iz16mr21397670wic.29.1399389535404; Tue, 06 May 2014 08:18:55 -0700 (PDT) Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id pl6sm22491146wjc.0.2014.05.06.08.18.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 May 2014 08:18:53 -0700 (PDT) From: Thomas Monjalon To: "Burakov, Anatoly" Date: Tue, 06 May 2014 17:18:52 +0200 Message-ID: <3138330.LfuR0euKkp@xps13> Organization: 6WIND User-Agent: KMail/4.13 (Linux/3.14.2-1-ARCH; KDE/4.13.0; x86_64; ; ) In-Reply-To: References: <1398867304-21171-1-git-send-email-david.marchand@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 15:18:50 -0000 2014-05-06 10:05, Burakov, Anatoly: > David Marchand: > > 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 ? > > Sounds like an overcomplication to me. There could be cases where > performance doesn't matter, for example the -m switch could be used to run > various tests (unit tests, functional tests etc.). For anything > performance-related, the recommended option is to use --socket-mem, > especially if you have NICs on specific sockets. Presumably, when you're > setting up a coremask, you already know which sockets your cores are on, so > I don't see a problem with specifying which sockets you want memory from. Having --socket-mem option to explicitly configure NUMA is OK. Having -m option for simple configuration is OK. Making -m option working for most use cases would be really nice. So I don't understand why we shouldn't do this enhancement. I don't know if "overcomplication" is a good argument. Maybe we should wait the patch to discuss it. -- Thomas