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 55F4FA0C41; Wed, 17 Nov 2021 14:39:57 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4200941186; Wed, 17 Nov 2021 14:39:57 +0100 (CET) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) by mails.dpdk.org (Postfix) with ESMTP id A1EA341172 for ; Wed, 17 Nov 2021 14:39:56 +0100 (CET) Received: by mail-il1-f177.google.com with SMTP id i9so2768397ilu.8 for ; Wed, 17 Nov 2021 05:39:56 -0800 (PST) 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=ZC1WawVwFomiEPwK0ZWvbF0e7LW6c8FdcL7W1Vf1ibY=; b=IlGOMlCh5V9By+e4nUFE7lRW7iQn8V639dc/sF7kaxvgprxmt2dtykVVuIkNsioguN LwKFJSH68YXZcGuIVlEu4uam/+UnltVNGvmxfI7AM8Y1BZ9o/56SKsAqltpa+2DPChJ0 Y8rHFj+ibOwmrS8WzpmJ7bQzLl2sFpQPyMQ+FZFkCvUfv8xLiYC9qNa7f3jsmaIv0aUX dxB+FhnqvDxFoQKijDNIQlROLVyn1pQVcpMgDdpt55pSNMxDrOLXVYNhy2UZlF+KBQF/ qnCPc70VZyMEhr0hMokraV3ZKvABw/8wu4r4SgXvpyx8JgEaQTBvvIpYvUXwhJLaxa7m +7JQ== 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=ZC1WawVwFomiEPwK0ZWvbF0e7LW6c8FdcL7W1Vf1ibY=; b=ZwdNtx1sLuxklV5O7r2/ORSj5DV8/QGI05JVGU5bTiG4g1b3JWb0mXzfU6q43puPTN P5BR9FTtHwTraU1qJBPNxb0c2iwFPnB3Yrb2+m9ViXcof3WMqlM5Brvu3wqowRmr+LvO 2YUu5EZDM2M2Xj5rZkkqsAiTXvrCD4Idpz+Kkvrtc+gDnpLhT20ZjYCGgzqwOTqYxtTw F02tiPXUnQzla0Xwf40c34VR4hN8Te9UfGXiMkJ7tElDnTHkt6nkAhVCkZnOJbISeMkW V6dQlEDoKryicMN+uuhDWk/5FxA3weCPwhiZr2lpObTb1TNcMAvAT350qcPBxjZs8BVA U9qQ== X-Gm-Message-State: AOAM533/CVTGVYJ+r1iFLr9VDhLGqShzogFcsOqIA5wlP2JJHcr4amcA zWalsI9LhbEA9jQc00hzfnhjQw4t2HYmWCj6/4M= X-Google-Smtp-Source: ABdhPJyhIvnSpZMi3eTHjX4Lnuy15L8ThL4MTT4RVt5pGXiB0ga873UsA4AZwg/aYOT/PEsoXYGBoVq9w4Y6vhtOVDw= X-Received: by 2002:a92:c56b:: with SMTP id b11mr10385170ilj.243.1637156395963; Wed, 17 Nov 2021 05:39:55 -0800 (PST) MIME-Version: 1.0 References: <20211029204909.21318-1-eagostini@nvidia.com> <20211117030459.8274-1-eagostini@nvidia.com> <20211117030459.8274-2-eagostini@nvidia.com> <20211116133449.7b7d21d1@hermes.local> <20243569-b7f0-53c5-02c5-ba29734e30c2@intel.com> In-Reply-To: From: Jerin Jacob Date: Wed, 17 Nov 2021 19:09:29 +0530 Message-ID: Subject: Re: [PATCH v3 1/1] app/testpmd: add GPU memory option for mbuf pools To: Elena Agostini Cc: "Ananyev, Konstantin" , "Yigit, Ferruh" , "Richardson, Bruce" , Stephen Hemminger , "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, Nov 17, 2021 at 6:09 PM Elena Agostini wrote: > > > > >> > > > > >>>> > > > > >> > > > > >>>>> On Wed, 17 Nov 2021 03:04:59 +0000 > > > > >> > > > > >>>> > > > > >>>>>> This patch introduces GPU memory in testpmd through the gpudev library. > > > > >> > > > > >>>> > > > > >> > > > > >>>>>> Testpmd can be used for network benchmarks when using GPU memory > > > > >> > > > > >>>> > > > > >> > > > > >>>>>> instead of regular CPU memory to send and receive packets. > > > > >> > > > > >>>> > > > > >> > > > > >>>>>> This option is currently limited to iofwd engine to ensure > > > > >> > > > > >>>> > > > > >> > > > > >>>>>> no workload is applied on packets not accessible from the CPU. > > > > >> > > > > >>>> > > > > >> > > > > >>>>>> > > > > >> > > > > >>>> > > > > >> > > > > >>>>>> The options chose is --mbuf-size so buffer split feature across > > > > >> > > > > >>>> > > > > >> > > > > >>>>>> different mempools can be enabled. > > > > >> > > > > >>>> > > > > >> > > > > >>>>>> > > > > >> > > > > >>>> > > > > >> > > > > >>>>>> Signed-off-by: Elena Agostini > > > > >> > > > > >>>> > > > > >> > > > > >>>>> > > > > >> > > > > >>>> > > > > >> > > > > >>>>> Won't this create a hard dependency of test-pmd on gpudev? > > > > >> > > > > >>>> > > > > >> > > > > >>>>> I thought gpudev was supposed to be optional > > > > >> > > > > >>>> > > > > >> > > > > >>>> > > > > >> > > > > >>>> > > > > >> > > > > >>>> Sure, let me submit another patch to make it optional > > > > >> > > > > >>> > > > > >> > > > > >>> Why to add yet another compile time macro everywhere in testpmd and > > > > >> > > > > >>> make hard to maintain? > > > > >> > > > > >>> Adding iofwd kind of code is very simple to add test/test-gpudev and > > > > >> > > > > >>> all GPU specific options > > > > >> > > > > >>> can be added in test-gpudev. It also helps to review the patches as > > > > >> > > > > >>> test cases focus on > > > > >> > > > > >>> each device class. > > > > >> > > > > >> > > > > >> > > > > >> Test-gpudev is standalone unit test to ensure gpudev functions work correctly. > > > > >> > > > > >> In testpmd instead, there is a connection between gpudev and the network. > > > > > > > > > > I understand that. We had the same case with eventdev, where it needs to > > > > > work with network. Testpmd is already complicated, IMO, we should > > > > > focus only ethdev > > > > > test cases on testpmd, test-gpudev can use ethdev API to enable > > > > > networking requirements for gpudev. > > > > > > > > > > > > > +1 > > > > > > +1 > > > > Testpmd already manages different type of memories for mempools. > > gpudev is just another type of memory, there is nothing more than that. Let take this example: 1) New code changes app/test-pmd/cmdline.c | 32 +++++++- app/test-pmd/config.c | 4 +- app/test-pmd/icmpecho.c | 2 +- app/test-pmd/meson.build | 2 +- app/test-pmd/parameters.c | 15 +++- app/test-pmd/testpmd.c | 167 +++++++++++++++++++++++++++++++++++--- app/test-pmd/testpmd.h | 16 +++- 7 files changed, 217 insertions(+), 21 deletions(-) 2) Good amount of code need to go through condition compilation as gpudev is optional that make testpmd further ugly. 3) It introduces new memtype, now +enum mbuf_mem_type { + MBUF_MEM_CPU, + MBUF_MEM_GPU +}; The question largely, why testpmd need to pollute for this, testpmd, we are using for testing ethdev device class. All we are saying is to enable this use case in test-gpudev so that it focuses on GPU specific, Whoever is not interested in specific libraries do not even need to review the testpmd patches.