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 34A82A0C41; Wed, 17 Nov 2021 14:50:31 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E2ACB41165; Wed, 17 Nov 2021 14:50:30 +0100 (CET) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2082.outbound.protection.outlook.com [40.107.236.82]) by mails.dpdk.org (Postfix) with ESMTP id 1BB544114D for ; Wed, 17 Nov 2021 14:50:30 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O7CFqLByLHOQGoe8x563jZXiLBcXu8l1X6eCnXYntRO9ICAxcOL/E/qrWvMlFE9YLmjYw+tUirelaPdQXprBBjdoINefgqaUs0ds6wKMWgvzGgoIKQvfds0901i/bDcaT9qlJhqKiIDDPjT677T4p5h/t+lobt7CxuxHxsjlhABThskj7mlPeyxMdoRS7EpkgnmYZPRZhiICKohcL6E4lX+pX5goPx4DzXX0QhYVX0HnTZaWq9JZemmGn+FaxzJKx8HT+c74HALWEE2Nn7Tag0PBjOQ44MYz61QhuaDIC1Cwf6YF4ey4pjqDWAxc/vpakhhKYBUyPCsKiLcucHxRnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gIC5nsxY99Xg0fSyciLb9sx6ofC7KoIdnC/HKGI7Av8=; b=PNwbrkVyWyYtSsyPs1wYXFucW2siibtf626UOJnb/jmU/SctRI/p7YTuN22DVYXrjGgsZY4EdebhuUHRMSTulgWoZVlZ1MCoUFfU8Mvj+sQagVaIlZdL4oz21sHmpXtOyh/5wGLG4y/Wq+hQZJK08/VmTkt2TbXX6dVhospLuTqjnCWA9+/bO7FRdwpwU9RWRpdaUUmGRtjvMAIg+jB64sy6KbFttXpqgMKwXK9eW2078/mP2leMcjWAVuQIkGWwfxLcLUEGkOYxk7cg1HMoJOGNw4EcwjmGI9wHD1XMa73L1YznuG9AhnxqxcfxMFgpqkaGDVLcXKDRHwbFO0J3EQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gIC5nsxY99Xg0fSyciLb9sx6ofC7KoIdnC/HKGI7Av8=; b=do3TZAZRb5hGN4IENWJSzcUL0jWzQUsVildRJnGnFjrIYMZ3R83Smy3OTjeESbC939ohSX0qyYRa1rrrZ2HPBZ7khmgLH8WB3OxCSkX6x1kVJE4luhqoNWDVKfrESRFPe8i6BHT2mFXEPhBTV5SczkqUpOc7priKWBiuGWHQJAwVb77316Wox6sgMrrK0KZC1SqxlH7g138FNmevVnHtxvZfG0JOnHT6x4uyURwEELzsx+X7s6o8I8npqQp8jlmG9lFVTIfflidzSsGX8iZES28c2Fjq5kbYrtCrfx089UPAnSCqpvsLXn2LyPc2xhENvBsQwM+ZkGUp7PXpEl/Gig== Received: from DM6PR12MB4107.namprd12.prod.outlook.com (2603:10b6:5:218::7) by DM5PR1201MB0059.namprd12.prod.outlook.com (2603:10b6:4:54::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.21; Wed, 17 Nov 2021 13:50:28 +0000 Received: from DM6PR12MB4107.namprd12.prod.outlook.com ([fe80::98ea:e961:8212:62f4]) by DM6PR12MB4107.namprd12.prod.outlook.com ([fe80::98ea:e961:8212:62f4%7]) with mapi id 15.20.4713.021; Wed, 17 Nov 2021 13:50:26 +0000 From: Elena Agostini To: Jerin Jacob CC: "Ananyev, Konstantin" , "Yigit, Ferruh" , "Richardson, Bruce" , Stephen Hemminger , "dev@dpdk.org" Subject: Re: [PATCH v3 1/1] app/testpmd: add GPU memory option for mbuf pools Thread-Topic: [PATCH v3 1/1] app/testpmd: add GPU memory option for mbuf pools Thread-Index: AQHX2xtuLnccivIdaEyRk5cICPLtBqwGrVmAgADi4JqAAATLgIAAAH8ygAABeoCAAATgAIAADV+AgAAAvt6AABDlgIAAAnYk Date: Wed, 17 Nov 2021 13:50:26 +0000 Message-ID: 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: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89275d0f-66cf-4bb4-01bf-08d9a9d135b3 x-ms-traffictypediagnostic: DM5PR1201MB0059: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7hg1xyArc1eLowYALzCzaZEJ/agERXJUIcEaQLLC4hCUzTwvziNiB+AXe2YLZ2qNmyKnWysC1my0CnWv+6aWfvOetkW2+v+fIhj42LJRVmRdya2E9ocAlgsH1KHJ95+3h1pEKGCkSi9D91mxo7RAfjbvHi/Kz7Bccp4wkSC6gujE0m67aml9l+6bzro680eZxMDG/FHv5kMAHEihUhMHtzTEdRPyFuWIKxNyIS5s1HVhYecutL6LWcPRGWvtI4gIpHnMWYrHIGCN1m2eRoqFs5DhR3s5IX9sJcTZYYA4aiJEh0ACJKmmMiCjptxlzl5ZyH8xyoVNrCpfPTlrCR5gRY5PP06RxWe/B10qhLIGJ2uxF23254rEaYqeJW6gK1yLKSPqdbH6VkBtrgGkhLxLjnf9Hi7Pqvtgl0RUZA92vql/xTPjixyLVP/WnjTkP34K6KmrCquJPsaigZDPRHXSEaXcukiSx69cz/DoqEJp6HBarBS3iIryIIlQeBIA2kbhM15xs7yhkDo+A4TZegT2lTZQkHtyiCKkHKJIkADxZQB9nzlDGn0x8iuLd+Zxepbsac6f0OG0lo7TaZT0OgpfJqdL+sjGuwz35H3hZMYpQ8XW5ghEwgd3Ot4ka5oMZfWbwTJeh6E+J4ITlhYjVdAn3/CRPsfTDEMXFt8aPMslotv2F+TStRhmOUiiU3MHgnVSOtz2/5wFVQftL9miIz2Agg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB4107.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(7696005)(186003)(8676002)(71200400001)(6506007)(53546011)(8936002)(26005)(6916009)(508600001)(4326008)(33656002)(2906002)(316002)(86362001)(54906003)(122000001)(83380400001)(38100700002)(38070700005)(5660300002)(55016002)(66946007)(66556008)(9686003)(64756008)(66446008)(66476007)(52536014)(91956017)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?A1DfGVkmhvc6rSPcXSxOynkW1MBOYKk5em6+ngBmQkZiNTBA6XYcIthb?= =?Windows-1252?Q?QOhbwMWoi+qKe5PmlG6vekLHgowv8+zqMbLZF6va2kkCjbxtqyuBkzC4?= =?Windows-1252?Q?KT3Ru5EQyjna23TQN/tFhgEvXG704caY2o56Y3R42+he0JHhpNcqyipI?= =?Windows-1252?Q?LmtZ3hJ9AUaVrMgMzdm95zG7f2e/hbIBHrvyQN+hSE6OlP6fo/BPwrII?= =?Windows-1252?Q?m7kjzi5ocE4SyKKYGJJuI+CO7RJVjh/7TbfhjY/KEBwSSgdCzA13XxZN?= =?Windows-1252?Q?IMKpLv6GaMRlpjRog1hfcWj/QqKObRPJVj4xXdhYFE/oCQ5IpG2Jqimg?= =?Windows-1252?Q?9S77XyD4yWaIfcfKjidcm8wnBpRzfz2uN5fvsxw1q4wdpwfrl1z1pYNg?= =?Windows-1252?Q?JSXvG+Sgrb2Fw8w6NJZeVJPLtzoe1Zw/LBsEX09hqVGH+/pyRu7HiOk7?= =?Windows-1252?Q?LasNYjBvpgp8982X3w6oi9Od/9GR4eO98pkGIYIcnRW/wzcFTrWulRAE?= =?Windows-1252?Q?+1gmlSaiMSGBEpiAj0SOS4y9nHWlhgCtm95FT3Pf2uuUrxaiB03K6heb?= =?Windows-1252?Q?pFWMNgbA09RWWGIeKvnQF5wc+JuxtvWIwaMDJ7agmGup/w6TSZeRB/x/?= =?Windows-1252?Q?lLVchjHYuqP0U6993wBOsFWfVZfU6ZYJ1gHQTKyxBn3JtZUvC1FxJLaI?= =?Windows-1252?Q?W+IJn0oXPQ7vjqe0JTzNBviaAarjpdkzxpMJUsxe0ePxOfFO3biiTIF9?= =?Windows-1252?Q?tKwBZGi6cu/e4AZz0dETZIyUCOn1jH1V2+ml1tXz5NF9J96YUTHdSsDw?= =?Windows-1252?Q?RZk+G8JF6z0AaszAtWWm0y/T7+m2khZy6VZY4Vpan75eZSI8XFqaxZSZ?= =?Windows-1252?Q?WsF5AMPvABLZpwBnBojKZ6+kzIHS99l2oYX77hOnYu1q2SU/2NlUedCy?= =?Windows-1252?Q?VfAg/S1LC0XKPjhpUiLf+4aUmRxoHt+2HxIjXy2DGCAg0VD04C1uO682?= =?Windows-1252?Q?PuE8cPbHa8DU0kECSy+2HJd+qNdNkF4j3hD8gWEbNo5sqogWE+YfucHp?= =?Windows-1252?Q?vXmXQx34fLbljQV+7zX2gBR82/FUYVdGYIozjn+XaFegYIKZOqkFD5RI?= =?Windows-1252?Q?c0EqhNLLZY0js6OpGfuwZqvKZPmD6usVuFYqqBUGFISecAphR+K9QDba?= =?Windows-1252?Q?f+Mem0BCvKYWVsID8mW9n6dJsnrwWO/PlklmSFgldeZ/Dv2XlvrpcCgt?= =?Windows-1252?Q?JtuShWpcnxr5sWzp/qg90xzc+P9dxoLW2J4wXAmgfjkYVBNt+Hb6g5k1?= =?Windows-1252?Q?9eyNdVaL+qiz12AdVvEMKJn5BWE+b+HtSfM4RaWDxWvqSmeFYe4mjThQ?= =?Windows-1252?Q?Au2eZuuK2DIAvvuj0fniZjFc8AxYQvxTd0QHv+L8EBuQ6gPOKfX3XOqW?= =?Windows-1252?Q?tdChv8HGa9MB2NIn7f3ktjKoU13IBopdIoEy3shDN8XtKTRVBHCvw7BE?= =?Windows-1252?Q?6jb1YL9A86odqNZI50BJCjxqRB1en8lQXZWfoh092lJjGMTNbTVmFrNo?= =?Windows-1252?Q?PIipWgzLFYQRwy2NX0zCFeeKtsJIHMhFVCyawEXUfWjWBFeoFEw8lm/s?= =?Windows-1252?Q?7UmCJw6XLUnfqUj3EAMO+nYBvZ+Bcn1lXRG0LKRWITyMyf2clyESPhHu?= =?Windows-1252?Q?r9ezANOXZE8A2ou3x+7pp+aQgzojL0Q1K/weSGRgGgm8dzhygZB0OBk6?= =?Windows-1252?Q?+vfG7ihBSYLQp5ug8c7VO8XdLD/jkM6B60XRxDgH?= Content-Type: multipart/alternative; boundary="_000_DM6PR12MB4107D9DD7A3104C6E309B110CD9A9DM6PR12MB4107namp_" MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB4107.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89275d0f-66cf-4bb4-01bf-08d9a9d135b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2021 13:50:26.2703 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: j7HzVxAczEpr9Uvv0tLNTGTbjAPnZJdDfZw+Fk2rSSll6Y4HpIUDE+BUgMca4bjmFkEnNZzGo9LAb0BNdcoLmQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1201MB0059 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 --_000_DM6PR12MB4107D9DD7A3104C6E309B110CD9A9DM6PR12MB4107namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > On Wed, Nov 17, 2021 at 6:09 PM Elena Agostini wro= te: > > > > > > >> > > > > > > >>>> > > > > > > >> > > > > > > >>>>> On Wed, 17 Nov 2021 03:04:59 +0000 > > > > > > >> > > > > > > >>>> > > > > > > >>>>>> This patch introduces GPU memory in testpmd through the gpud= ev library. > > > > > > >> > > > > > > >>>> > > > > > > >> > > > > > > >>>>>> Testpmd can be used for network benchmarks when using GPU me= mory > > > > > > >> > > > > > > >>>> > > > > > > >> > > > > > > >>>>>> 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 CP= U. > > > > > > >> > > > > > > >>>> > > > > > > >> > > > > > > >>>>>> > > > > > > >> > > > > > > >>>> > > > > > > >> > > > > > > >>>>>> The options chose is --mbuf-size so buffer split feature acr= oss > > > > > > >> > > > > > > >>>> > > > > > > >> > > > > > > >>>>>> 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-gpude= v and > > > > > > >> > > > > > > >>> all GPU specific options > > > > > > >> > > > > > > >>> can be added in test-gpudev. It also helps to review the patche= s as > > > > > > >> > > > > > > >>> test cases focus on > > > > > > >> > > > > > > >>> each device class. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> Test-gpudev is standalone unit test to ensure gpudev functions w= ork 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 n= eeds 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 p= atches. I understand your point. I don=92t understand why this testpmd patch is the= re since Oct 29 but I'm receiving reviews only few days before rc4 when I have a limited amount= of time to get new code accepted. I can provide a gpudev + ethdev example by end of today (I'd like to keep t= est-gpudev as it is to test gpudev API standalone). Is there any chance this new example will be reviewed and eventually accept= ed in DPDK 21.11? --_000_DM6PR12MB4107D9DD7A3104C6E309B110CD9A9DM6PR12MB4107namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> On Wed, Nov 17= , 2021 at 6:09 PM Elena Agostini <eagostini@nvidia.com> wrote:

> >

> > > >= >>

> >

> > > >= >>>>

> >

> > > >= >>

> >

> > > >= >>>>> On Wed, 17 Nov 2021 03:04:59 +0000<= /p>

> >

> > > >= >>

> >

> > > >= >>>>

> >

> > > >= >>>>>> This patch introduces GPU memory in testpmd throu= gh the gpudev library.

> >

> > > >= >>

> >

> > > >= >>>>

> >

> > > >= >>

> >

> > > >= >>>>>> Testpmd can be used for network benchmarks when u= sing 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 <eagostini@nvidi= a.com>

> >

> > > >= >>

> >

> > > >= >>>>

> >

> > > >= >>

> >

> > > >= >>>>>

> >

> > > >= >>

> >

> > > >= >>>>

> >

> > > >= >>

> >

> > > >= >>>>> Won't this create a hard dependency of test-pmd on gp= udev?

> >

> > > >= >>

> >

> > > >= >>>>

> >

> > > >= >>

> >

> > > >= >>>>> 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 testp= md and

> >

> > > >= >>

> >

> > > >= >>> make hard to maintain?

> >

> > > >= >>

> >

> > > >= >>> Adding iofwd kind of code is very simple to add test/test-gpu= dev and

> >

> > > >= >>

> >

> > > >= >>> all GPU specific options

> >

> > > >= >>

> >

> > > >= >>> can be added in test-gpudev. It also helps to review the patc= hes as

> >

> > > >= >>

> >

> > > >= >>> test cases focus on

> >

> > > >= >>

> >

> > > >= >>> each device class.

> >

> > > >= >>

> >

> > > >= >>

> >

> > > >= >>

> >

> > > >= >> Test-gpudev is standalone unit test to ensure gpudev functions wo= rk 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<= /o:p>

> >

> > > >= > networking requirements for gpudev.

> >

> > > >= >

> >

> > > >=

> >

> > > >= +1

> >

> > >=

> >

> > > +1

> >

> >

> >

> > Testpmd a= lready 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 ch= anges

>

 > app/test= -pmd/cmdline.c    |  32 +++++++-

> app/test-pmd/c= onfig.c     |   4 +-

> app/test-pmd/i= cmpecho.c   |   2 +-

> app/test-pmd/m= eson.build  |   2 +-

> app/test-pmd/p= arameters.c |  15 +++-

> app/test-pmd/t= estpmd.c    | 167 +++++++++++++++++++++++++++++++++++---

> app/test-pmd/t= estpmd.h    |  16 +++-

> 7 files change= d, 217 insertions(+), 21 deletions(-)

>

> 2) Good amount= of code need to go through condition compilation as

> gpudev is opti= onal that make

> testpmd furthe= r ugly.

>

> 3) It introduc= es new memtype, now

>

> +enum mbuf_mem= _type {

> + MBUF_MEM_CPU= ,

> + MBUF_MEM_GPU=

> +};=

>

> The question l= argely, why testpmd need to pollute for this, testpmd,

> we are using f= or testing ethdev device class.

> All we are say= ing is to enable this use case in test-gpudev so that it<= /p>

> focuses on GPU= specific, Whoever is not

> interested in = specific libraries do not even need to review the testpmd patches.

 

I understand your p= oint. I don=92t understand why this testpmd patch is there since Oct 29 but

I'm receiving revie= ws only few days before rc4 when I have a limited amount of time to get new code a= ccepted.

 

I can provide a gpu= dev + ethdev example by end of today (I'd like to keep test-gpudev as it is to test gpudev API standalone).

Is there any chance this new example will be reviewed and eventua= lly accepted in DPDK 21.11?<= /p>

--_000_DM6PR12MB4107D9DD7A3104C6E309B110CD9A9DM6PR12MB4107namp_--