From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9490EA04A5 for ; Thu, 18 Jun 2020 05:16:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4ADEF1023; Thu, 18 Jun 2020 05:16:08 +0200 (CEST) Received: from dish-sg.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp [202.19.227.74]) by dpdk.org (Postfix) with ESMTP id 87CF41023 for ; Thu, 18 Jun 2020 05:16:06 +0200 (CEST) X-dD-Source: Outbound Received: from zssg-mailmd103.ddreams.local (zssg-mailmd900.ddreams.local [10.160.172.63]) by zssg-mailou103.ddreams.local (Postfix) with ESMTP id C1F4D120101; Thu, 18 Jun 2020 12:16:05 +0900 (JST) Received: from t131sg-mailcc11.ddreams.local (t131sg-mailcc11.ddreams.local [100.66.31.86]) by zssg-mailmd103.ddreams.local (dDREAMS) with ESMTP id <0QC300AA0QETYXA0@dDREAMS>; Thu, 18 Jun 2020 12:16:05 +0900 (JST) Received: from t131sg-mailcc11 (localhost [127.0.0.1]) by t131sg-mailcc11.ddreams.local (unknown) with SMTP id 05I3G5a9003455; Thu, 18 Jun 2020 12:16:05 +0900 Received: from zssg-mailmf105.ddreams.local (unknown [127.0.0.1]) by zssg-mailmf105.ddreams.local (Postfix) with ESMTP id 899FC7E603B; Thu, 18 Jun 2020 12:14:53 +0900 (JST) Received: from zssg-mailmf105.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 862368E6066; Thu, 18 Jun 2020 12:14:53 +0900 (JST) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 83F008E605D; Thu, 18 Jun 2020 12:14:53 +0900 (JST) X-IMSS-HAND-OFF-DIRECTIVE: localhost:10026 Received: from zssg-mailmf105.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 100528E6052; Thu, 18 Jun 2020 12:14:53 +0900 (JST) Received: from zssg-mailua105.ddreams.local (unknown [10.160.172.62]) by zssg-mailmf105.ddreams.local (Postfix) with ESMTP; Thu, 18 Jun 2020 12:14:53 +0900 (JST) Received: from [10.87.198.18] (unknown [10.160.183.129]) by zssg-mailua105.ddreams.local (dDREAMS) with ESMTPA id <0QC301BXEQCSOJK0@dDREAMS>; Thu, 18 Jun 2020 12:14:52 +0900 (JST) Date: Thu, 18 Jun 2020 12:14:52 +0900 From: Hideyuki Yamashita In-reply-to: <2de0e4ca-1452-8370-53c1-b9dbefc948b7@gmail.com> References: <20200616173006.B8F5.17218CA3@ntt-tx.co.jp_1> <2de0e4ca-1452-8370-53c1-b9dbefc948b7@gmail.com> Message-id: <20200618121452.B90B.17218CA3@ntt-tx.co.jp_1> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: Becky! ver. 2.74.02 [ja] X-TM-AS-GCONF: 00 To: Yasufumi Ogawa Cc: x-fn-spp-ml@ntt-tx.co.jp, spp@dpdk.org Subject: Re: [spp] (x-fn-spp-ml 796) Re: (x-fn-spp-ml 783) Re: [PATCH 5/5] docs: add note regarding NUMA configuration X-BeenThere: spp@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Soft Patch Panel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spp-bounces@dpdk.org Sender: "spp" Hello, Thanks for your comments. Please see inline. > > Hi. > > Sorry for delayed response. > > Please see my comments inline. > > > >>> From: Hideyuki Yamashita > >>> > >>> This patch adds new notes for NUMA configuration when starting > >>> spp_primary. > >>> > >>> This is pointed out by the following DPDK Bugzilla tickets. > >>> https://bugs.dpdk.org/show_bug.cgi?id=457 > >>> > >>> Signed-off-by: Hideyuki Yamashita > >>> Signed-off-by: Naoki Takada > >>> --- > >>> docs/guides/gsg/howto_use.rst | 12 ++++++++++++ > >>> 1 file changed, 12 insertions(+) > >>> > >>> diff --git a/docs/guides/gsg/howto_use.rst b/docs/guides/gsg/howto_use.rst > >>> index f182198..4f2e6cd 100644 > >>> --- a/docs/guides/gsg/howto_use.rst > >>> +++ b/docs/guides/gsg/howto_use.rst > >>> @@ -422,6 +422,18 @@ if you run the process on single NUMA node. > >>> If you use DPDK v18.11 or later, ``--base-virtaddr 0x100000000`` is enabled > >>> in default. You need to use this option only for changing the default value. > >>> > +.. note:: > >>> + > >>> + ``spp_primary`` tries to create memory pool in the same NUMA node where > >>> + it is launched. Under NUMA configuration, the NUMA node where ``spp_primary`` > >>> + is launched and the NUMA node where NIC is connected can be different > >>> + (e.g. spp_primary runs in NUMA node 0 while NIC is connected with NUMA > >>> + node 1). > >>> + Such configuration may cause performance degradation. In general, under > >>> + NUMA configuration, it is best practice to use CPU and NIC which belongs > >>> + to the same NUMA node for best performance. So user should align those > >>> + when performance degradation makes the situation critical. > >>> + > >> I have two comments. > >> > >> 1. Could I confirm WHAT should be configured for avoiding such a performance loss? > > > > NUMA node > > - primary process will run (that can be specified with -l parameter) > > - NIC belongs > > should be the same to avoid performance loss. > > > > In general, topology regarding with NUMA node > > (e.g. CPU core, NIC which is connected with specific NUMA node) > > can be found in lstopo command. > I would like to make it clear as an instruction for users. From my understanding, users should confirm that > - Understand layout of hardware architecture of NICs and CPUs. > - Assign lcores while launching spp_primary by considering the layout identified before. > > I understand your update for explanation is collect, but not so clear the purpose as instruction. >I think it could be more agreeable if you start to explaining WHAT can >be happened if you do not care about the layout (performance >degradation actually), then HOW you get the layout by using `lstopo` >and HOW you configure lcores by using `-l` option. OK. I think in general we can agree on the concept of the change. I think it might be better that - I add description in the "Performance Optimization" section because it is highly related with "Performance"! - Firstly I should explain "what will happen" if such consideration is NOT taken into account by users - Secondary I should describe "how" users can avoid such performance degradations (e.g. use lstopo command, specify appropriate lcore when starting up spp_primary process) Anyway I think it is better to discuss above over "actual" changes. Thanks I will send revised version of the patch when it got available. BR, Hideyuki Yamashita > Thanks, > Yasufumi > > > > > > >> 2. It seems something abruptly considering context of this section because you start talking about performance suddenly. > >> If it must be considered as a mandatory configuration and should be explained this section, I agree your update. > >> On the other hand, what do you think to move this note to the next "Performance Optimization" section. > >> I think no need to be a note if you move it to the next secion. > > > > I agree with your idea. > > I think it is NOT mandatory, thus should be moved to next section > > 'without' note. > > > >> > >> Thanks > >> > >>> If ``spp_primary`` is launched with two or more lcores, forwarder or monitor > >>> is activated. The default is forwarder and monitor is optional in this case. > >>> If you use monitor thread, additional option ``--disp-stat`` is required. > > > >