From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A2ACEA00C2 for ; Mon, 23 May 2022 15:16:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2D1544014F; Mon, 23 May 2022 15:16:34 +0200 (CEST) Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) by mails.dpdk.org (Postfix) with ESMTP id 400FC40141 for ; Mon, 23 May 2022 15:16:32 +0200 (CEST) Received: by mail-oi1-f177.google.com with SMTP id v9so13068678oie.5 for ; Mon, 23 May 2022 06:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=szevhNKM9zgwujp+R7dU9Sf0RkM3o9WmYcYuMoBENbc=; b=qg/dsXgMpYpNFcqQ7BHsGOIx5VZMGuSeqxnNPi3VVgLmaxpBRQs1T6t1bxGhq5lxp/ S2t8YR6PfJ6GGnm5JO6uA4ELeUhTtIIohj/7MbqErv9d559/Pzw3UxJ7cxcFbM3Mf8JL ETuXUmZZeLBkcWDZgZYdntbXKaEwqyGDMWJ92+xHhwltUubbYD8mQKUb3lmjo9stQWDa 4GNUm/0U5JGM7r7eqF3VYVXysQseXfWdE00v6kVsiXcFS3v7VEU09M7m/8mT3hr54LsQ DMJnNgx3FpIeXvvH+bFWZKtU17nW5OuHTCtw54wHRqsEiAZh4FVrAzPEfZnpyoObwOvM BFww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=szevhNKM9zgwujp+R7dU9Sf0RkM3o9WmYcYuMoBENbc=; b=vd7uc4eweYiRiat8in9xvqhD5s6HRUY59ytGbFuFXb0UbsVaxB3FwVTwFct+zOvIJT YaPg6/GjXn/VL3Vjjuj8FPfnbq/g6KUhiP+mbQsXt1vcVmiT2LNq4RSk/19RdPUQPFIX +QsRz7iVlWnZtKWSm5f0U60hyorB5a3X1YxUAyTQ1dsqIf+lH1RUIfJq6nnDPnntnl3U FkcX7gyli1hGDjbtmP7V07F6C4ELAoDyeCFsnwMO/F5f+/E3uOxHvJCDtjtQCJ7Rl+Ih nqB7UoEQaVxKzzmyv+Eu28Q1EA4mBlCxY48hKqcLml8wxinkEd5QC927RCTrKE0rfdi+ m5gA== X-Gm-Message-State: AOAM530tYIw4yjqFuJql1emCojn2mxdYooMOXXrOQrtmc9d1jwrAgO5t rrvHryg/jodnhuMzm6DClevaZtkMcTCBnBucKMo= X-Google-Smtp-Source: ABdhPJxuUnL8WhffO/F06Zae61x6CFhcBvhdmmIIGNkFxF9aB5yi9JSisMAcwx7QqgwpED5EDEO1bNbHc2GayokKk0M= X-Received: by 2002:aca:a8d7:0:b0:328:b19f:dbac with SMTP id r206-20020acaa8d7000000b00328b19fdbacmr11603740oie.243.1653311791330; Mon, 23 May 2022 06:16:31 -0700 (PDT) MIME-Version: 1.0 References: <20220520084843.698f04ee@hermes.local> In-Reply-To: From: Antonio Di Bacco Date: Mon, 23 May 2022 15:16:20 +0200 Message-ID: Subject: Re: Optimizing memory access with DPDK allocated memory To: Stephen Hemminger Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Got feedback from a guy working on HPC with DPDK and he told me that with dpdk mem-test (don't know where to find it) I should be doing 16GB/s with DDR4 (2666) per channel. In my case with 6 channels I should be doing 90GB/s .... that would be amazing! On Sat, May 21, 2022 at 11:42 AM Antonio Di Bacco wrote: > > I read a couple of articles > (https://www.thomas-krenn.com/en/wiki/Optimize_memory_performance_of_Intel_Xeon_Scalable_systems?xtxsearchselecthit=1 > and this https://www.exxactcorp.com/blog/HPC/balance-memory-guidelines-for-intel-xeon-scalable-family-processors) > and I understood a little bit more. > > If the XEON memory controller is able to spread contiguous memory > accesses onto different channels in hardware (as Stepphen correctly > stated), then, how DPDK with option -n can benefit an application? > I also coded a test application to write a 1GB hugepage and calculate > time needed but, equipping an additional two DIMM on two unused > channels of my available six channels motherboard (X11DPi-NT) , I > didn't observe any improvement. This is strange because adding two > channels to the 4 already equipped should make a noticeable > difference. > > For reference this is the small program for allocating and writing memory. > https://github.com/adibacco/simple_mp_mem_2 > and the results with 4 memory channels: > https://docs.google.com/spreadsheets/d/1mDoKYLMhMMKDaOS3RuGEnpPgRNKuZOy4lMIhG-1N7B8/edit?usp=sharing > > > On Fri, May 20, 2022 at 5:48 PM Stephen Hemminger > wrote: > > > > On Fri, 20 May 2022 10:34:46 +0200 > > Antonio Di Bacco wrote: > > > > > Let us say I have two memory channels each one with its own 16GB memory > > > module, I suppose the first memory channel will be used when addressing > > > physical memory in the range 0 to 0x4 0000 0000 and the second when > > > addressing physical memory in the range 0x4 0000 0000 to 0x7 ffff ffff. > > > Correct? > > > Now, I need to have a 2GB buffer with one "writer" and one "reader", the > > > writer writes on half of the buffer (call it A) and, in the meantime, the > > > reader reads on the other half (B). When the writer finishes writing its > > > half buffer (A), signal it to the reader and they swap, the reader starts > > > to read from A and writer starts to write to B. > > > If I allocate the whole buffer (on two 1GB hugepages) across the two memory > > > channels, one half of the buffer is allocated on the end of first channel > > > while the other half is allocated on the start of the second memory > > > channel, would this increase performances compared to the whole buffer > > > allocated within the same memory channel? > > > > Most systems just interleave memory chips based on number of filled slots. > > This is handled by BIOS before kernel even starts. > > The DPDK has a number of memory channels parameter and what it does > > is try and optimize memory allocation by spreading. > > > > Looks like you are inventing your own limited version of what memif does.