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 10989436D4; Tue, 12 Dec 2023 19:13:04 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 90A0E42E64; Tue, 12 Dec 2023 19:13:03 +0100 (CET) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2044.outbound.protection.outlook.com [40.107.237.44]) by mails.dpdk.org (Postfix) with ESMTP id 76DF742E2D; Tue, 12 Dec 2023 19:13:02 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d9osvqsonDH1Mt1/lHuVOOwZvAYcf/4RqSlHP3ZL+R634ywTIN9jw4mNwq0QckIaYoBDByLxRVBCWrYJTejEXWRPyc3gDeFARBtim1PVHBpl/SMvI0ktc4gx7kW7wk+ctVc5N5wg8/5LaLDwuZz4uzG8tKddi48kiflG+4aGtEK6+B/ed+nS8WUBczNlvOuqGM45M9yxIQnS++pmOlKInosR/iRxNViaDIkdlOBNODVbaQ5+F9wGDcJI2e9YLW6ZJy56kKbtlByhYF18eT21FQAAS011fRt5Dh7baGzp5RgtEmn8ouQyYsPlrhXYuOYKLSionCgAQa6Sz0rbREseRg== 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=5VJWUeOf5JaNU3GHidMKODDUJexRV4BwLsSVkOQ2NNw=; b=enrymdXGIAw0jYvjtKFnFgDjblWxuJoSwYbM8K3NmkgsWNul1XhNT5OdophJ4QoIvMeFI1YEi82SQLesb976uL7dnnLzDlYCEZZKea4V0gKS0qNVFeMCYqN0BGUuMzbP3cAWJkXlEr+ANVLDnZ4iw6T3DE/NQsMzJN9Ecmgb2sMMqT0JKfjajeWAfnWaAfmGF0w6kPsIHpP6DT8eTqM76IHIy0z3yKw4vFJwIabTTpaecY/6nTfOBVb1aOYE+C4voeXomzK61e7LdhpfDye0uulJhDnQ6G5V8uK4uBaE+aMo9iRjNOnQsevhqUcy0AZs3b6uLks3c//vLTZ7WRu2WA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5VJWUeOf5JaNU3GHidMKODDUJexRV4BwLsSVkOQ2NNw=; b=kMLWVYvIsyQtHPam8IiTdhcyTe0ijUBxe4WT4LU0tnFhiH4F6wDCd9/dbYkbq7kVWZ9Msh03qiO/4+qZrH0vT5h1N2zfpWxVRwQCpLGd04dYJMTFzAoQHh2QYDGhSHAXyyq4/7RlGQek9SFEoatIMNODsDwVKH66QivhO4i/dqQ= Received: from MN2PR12MB3085.namprd12.prod.outlook.com (2603:10b6:208:c5::29) by BL0PR12MB4900.namprd12.prod.outlook.com (2603:10b6:208:1c1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7091.26; Tue, 12 Dec 2023 18:13:00 +0000 Received: from MN2PR12MB3085.namprd12.prod.outlook.com ([fe80::579d:6ed5:68a6:3cba]) by MN2PR12MB3085.namprd12.prod.outlook.com ([fe80::579d:6ed5:68a6:3cba%3]) with mapi id 15.20.7091.022; Tue, 12 Dec 2023 18:13:00 +0000 From: "Varghese, Vipin" To: =?Windows-1252?Q?Morten_Br=F8rup?= , Bruce Richardson CC: "Yigit, Ferruh" , "dev@dpdk.org" , "stable@dpdk.org" , "honest.jiang@foxmail.com" , "P, Thiyagarajan" Subject: Re: [PATCH] app/dma-perf: replace pktmbuf with mempool objects Thread-Topic: [PATCH] app/dma-perf: replace pktmbuf with mempool objects Thread-Index: AQHaLOc+P5veE9z1rka5g8pnqslJW7ClhhQAgAAxxICAAAqrAIAABemAgAAXjzyAABHz4IAAAd7o Date: Tue, 12 Dec 2023 18:13:00 +0000 Message-ID: References: <20231212103746.1910-1-vipin.varghese@amd.com> <98CBD80474FA8B44BF855DF32C47DC35E9F0BF@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F0C0@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F0C1@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F0C1@smartserver.smartshare.dk> Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Enabled=True; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_SetDate=2023-12-12T18:12:59.305Z; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Name=General; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_ContentBits=0; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Method=Standard; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN2PR12MB3085:EE_|BL0PR12MB4900:EE_ x-ms-office365-filtering-correlation-id: 29ace7e1-f233-41cb-7c4b-08dbfb3df98b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eXfmeHNbWdgJtrdtS0jAGWfYtmfA1Jx0O2eiDCptFCYkKr4EmsuOyo6HcRZ+7I3vcB6DPqdkJbRFFo67ICLOVgHRaKX1lr7tswmgUIldtE2xQfm5DaeKqb+iDqLcxqBNQvsaRdpxrsZ46xNpjSnTfAVU0nbnI2GOwfuQ1/T3nJOnvNgfS0Kf0ZJJZVDjn3UMdcbhgLUAF6mpEiyKdzw6IN45mAyT+/+8eYf5FcWCgWISbZDOnO1atztez4ulfnazbczEdcikovr6RqjFgmuDnq0sU+9FVAVZSi4lRNxnzeANwg2XBIKBsIsE4Kd0zmqO9S005Bg7az1B+tdFpV4xcR2wybvXCplMJBez8w8uN5sKJmedsIEsF+yJb+Qs8R1dxkumQiHUJGMzQDDnkmGLitaabpxH5ubWfGkcjgXuuwvT0/haEHPMRtLht/47r/f/4d2a4nHw/JnllodGxH/txKr+AevngDv+EJoS+kcJ+eAk/mBou7HJSQ3fLFuEq7Ph1giocOz6uJcHMVlSOvzEBkKZy71CyoFaoMplG5hrVclOrVug3WVQcyQQuTJGICYfizRmcGalxGYABIISgGp1srVF4iQKqbmhw99X2A+HGRsfeuw8gOwwrJpFkvcHL+uCRdHKpV5hepLBBXdYO7mb0elJQ6MPMZ+9/LWDLJs1ukCK/pNerUZu9lqs373Nz11x x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR12MB3085.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(136003)(376002)(396003)(346002)(366004)(230922051799003)(230273577357003)(230173577357003)(451199024)(1800799012)(64100799003)(186009)(38100700002)(66574015)(26005)(83380400001)(6506007)(7696005)(53546011)(9686003)(122000001)(8936002)(5660300002)(4326008)(52536014)(41300700001)(2906002)(8676002)(19627235002)(316002)(71200400001)(478600001)(54906003)(64756008)(66446008)(66556008)(66476007)(76116006)(91956017)(110136005)(33656002)(86362001)(66946007)(38070700009)(55016003)(19627405001)(48020200002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?W+3w+tLZWpE4RKNi0ypWHEEEEQSMV63Drl2zhDfOsvRK6z/DNNj0A5Z3?= =?Windows-1252?Q?nN64HHra3ZnDlB0v/PMgZRLXBsYrhnzEMlGApOO56Z7As0dQcyZPklSC?= =?Windows-1252?Q?MsiC5mE0e0dgB9ikWVZpwpU7Ntr5wM0HCNyHFKsnFaonyhgIrevCwxwI?= =?Windows-1252?Q?ACRu8yMx+8SWYagYJwtfXLceQB68Qge1Tm9ZT2hIVBEdUem2EzqVpwjQ?= =?Windows-1252?Q?Jz6iHgZFXCGLeQqKI4YJKvRWApMgj0eMR1Pwu2ezz8gW8D+ZXOz1M7FJ?= =?Windows-1252?Q?JIWCX7q8mCF5/Cf7sgDRhfwLRQuZlxzcN9HIl6pkJYVnazlK3DdeNAvJ?= =?Windows-1252?Q?PgwaqLKwhpCxBWknF2k/xRf4FkbJznetfOm6mOY0tc/r+BXXPMpLgjOs?= =?Windows-1252?Q?NQvPCTL9HQYt0K06+KHowS2y+bOXyx3e6MZqtefgCN0sOTCA6/7AxoAS?= =?Windows-1252?Q?EzSL1ACJn1JYGpl5C4B6gij27zxd6QtGdBuF3ajc0Nq2UPTSEfH319Jj?= =?Windows-1252?Q?zT+FSVB1lWFHUkNBh3Sur7LOv0jpYr34sRVoygQVTaJRIOsgJjxzhYKa?= =?Windows-1252?Q?6oIxVJHxhhUdf7wppJhwBNDQq4QoCod76AIfxEjmdA5MCYph8NOrTv08?= =?Windows-1252?Q?oBfMQmnpATSL3z9UFK9iorjemFa2FbajmIpCWqWpXp/BRVH+ycONnRGQ?= =?Windows-1252?Q?bu0uEHFk8VprnFsLFCqfJr1RRf7BbXFJnfkl7gusMQHJjTWfGzuOlkf8?= =?Windows-1252?Q?1uhxRlgvERnAV3NW1ejJgwXKhjq0ObUijX4ogjonNJsboJsV/4sqGj38?= =?Windows-1252?Q?6n24UhMcwN424D/iR81OMlQhfNSVjPrGYZ1nezSCUmK/6HTl1gyxSANS?= =?Windows-1252?Q?VJyvrLkP6iKCWTM/K2IxE+xxRUqL2ETGHln/Q1M24GEmfgh010jdWErZ?= =?Windows-1252?Q?sntYcK0XcNSqa7liO749f2rbfGsqfCnXfmNrsqDXtyHemtjT8Mwxp08o?= =?Windows-1252?Q?JVnihZVhn8ZXNeslgy8jqL6BcrOj1H1VtcRkKeG320ojXU0cDBzb6XwU?= =?Windows-1252?Q?LrVhtGw3h0UX+nPboWfchOz562cuHLkM5c/tsH74uQwuyzDL541lx7s6?= =?Windows-1252?Q?AZljAFU28SUMTK1zrcPTeH75v2y8iyucgnJBR+3qpNTU0Ig9ZoJDEMFL?= =?Windows-1252?Q?cqlmygbj5Od/ey6JcWPS8PtbtFXHvuma+e4mvXTOAF8bl2AsefbjGdIi?= =?Windows-1252?Q?73lWF5TFSgJ8xI09aaLRCbjMbKfZ5dvos6gHgRhQXEbnJWJVTt3vZ29L?= =?Windows-1252?Q?EPxeeO83Qw2zqsO34n3jajDdXnTwjq9ev+4w4jkm5K8qR+i1DEXZwKEy?= =?Windows-1252?Q?qEys815HiwzPulm9+KuYwoQwIBA+cISTJXxZvuZDs7bTYhQSb93lujhw?= =?Windows-1252?Q?m2B0g6DNvfJvYxaZ4gQXKTNmT6nvJklLwu4YRxasQXnoJ21oloieM2S3?= =?Windows-1252?Q?+nS5PN6OoYSN+sLhdKZVN2kox9dLw0Ury0jcM3IyGnMsqBSP3rYWKKc7?= =?Windows-1252?Q?ZQEgdNLLu5I7OgsY8bFMSpNYTxR+WgEaYStKfxPQa6UpkAbr3OTaaYex?= =?Windows-1252?Q?h9NpgP9P2WEyeGZCAABMWAfmqln2cSkFQXuGw4Im2DzH0yIkt90H2wzL?= =?Windows-1252?Q?05pj5HtIHyA=3D?= Content-Type: multipart/alternative; boundary="_000_MN2PR12MB30850F386E8FC5EE6DC066FF828EAMN2PR12MB3085namp_" MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB3085.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29ace7e1-f233-41cb-7c4b-08dbfb3df98b X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2023 18:13:00.0974 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ogJdiMLdj7zj6tOCKTkO+RAGCyhrrVb6EBW7XofO1FPKmmx3nMsc8aoHieeacRpLbZuh/7Iy1rmI0MBYlGDJQQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB4900 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_MN2PR12MB30850F386E8FC5EE6DC066FF828EAMN2PR12MB3085namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [AMD Official Use Only - General] Thank you Morten for the understanding ________________________________ From: Morten Br=F8rup Sent: 12 December 2023 23:39 To: Varghese, Vipin ; Bruce Richardson Cc: Yigit, Ferruh ; dev@dpdk.org ; stab= le@dpdk.org ; honest.jiang@foxmail.com ; P, Thiyagarajan Subject: RE: [PATCH] app/dma-perf: replace pktmbuf with mempool objects Caution: This message originated from an External Source. Use proper cautio= n when opening attachments, clicking links, or responding. From: Varghese, Vipin [mailto:Vipin.Varghese@amd.com] Sent: Tuesday, 12 December 2023 18.14 Sharing a few critical points based on my exposure to the dma-perf applicat= ion below On Tue, Dec 12, 2023 at 04:16:20PM +0100, Morten Br=F8rup wrote: > +TO: Bruce, please stop me if I'm completely off track here. > > > From: Ferruh Yigit [mailto:ferruh.yigit@amd.com] Sent: Tuesday, 12 > > December 2023 15.38 > > > > On 12/12/2023 11:40 AM, Morten Br=F8rup wrote: > > >> From: Vipin Varghese [mailto:vipin.varghese@amd.com] Sent: Tuesday, > > >> 12 December 2023 11.38 > > >> > > >> Replace pktmbuf pool with mempool, this allows increase in MOPS > > >> especially in lower buffer size. Using Mempool, allows to reduce the > > >> extra CPU cycles. > > > > > > I get the point of this change: It tests the performance of copying > > raw memory objects using respectively rte_memcpy and DMA, without the > > mbuf indirection overhead. > > > > > > However, I still consider the existing test relevant: The performance > > of copying packets using respectively rte_memcpy and DMA. > > > > > > > This is DMA performance test application and packets are not used, > > using pktmbuf just introduces overhead to the main focus of the > > application. > > > > I am not sure if pktmuf selected intentionally for this test > > application, but I assume it is there because of historical reasons. > > I think pktmbuf was selected intentionally, to provide more accurate > results for application developers trying to determine when to use > rte_memcpy and when to use DMA. Much like the "copy breakpoint" in Linux > Ethernet drivers is used to determine which code path to take for each > received packet. yes Ferruh, this is the right understanding. In DPDK example we already hav= e dma-forward application which makes use of pktmbuf payload to copy over new pktmbuf payload area. by moving to mempool, we are actually now focusing on source and destinatio= n buffers. This allows to create mempool objects with 2MB and 1GB src-dst areas. Thus = allowing to focus src to dst copy. With pktmbuf we were not able to achieve the same= . > > Most applications will be working with pktmbufs, so these applications > will also experience the pktmbuf overhead. Performance testing with the > same overhead as the application will be better to help the application > developer determine when to use rte_memcpy and when to use DMA when > working with pktmbufs. Morten thank you for the input, but as shared above DPDK example dma-fwd do= es justice to such scenario. inline to test-compress-perf & test-crypto-perf I= MHO test-dma-perf should focus on getting best values of dma engine and memcpy comparision. > > (Furthermore, for the pktmbuf tests, I wonder if copying performance > could also depend on IOVA mode and RTE_IOVA_IN_MBUF.) > > Nonetheless, there may also be use cases where raw mempool objects are > being copied by rte_memcpy or DMA, so adding tests for these use cases > are useful. > > > @Bruce, you were also deeply involved in the DMA library, and probably > have more up-to-date practical experience with it. Am I right that > pktmbuf overhead in these tests provides more "real life use"-like > results? Or am I completely off track with my thinking here, i.e. the > pktmbuf overhead is only noise? > I'm actually not that familiar with the dma-test application, so can't comment on the specific overhead involved here. In the general case, if we are just talking about the overhead of dereferencing the mbufs then I would expect the overhead to be negligible. However, if we are looking to include the cost of allocation and freeing of buffers, I'd try to avoid that as it is a cost that would have to be paid for both SW copies and HW copies, so should not count when calculating offload cost. Bruce, as per test-dma-perf there is no repeated pktmbuf-alloc or pktmbuf-f= ree. Hence I disagree that the overhead discussed for pkmbuf here is not related= to alloc and free. But the cost as per my investigation goes into fetching the cacheline and p= erforming mtod on each iteration. /Bruce I can rewrite the logic to make use pktmbuf objects by sending the src and = dst with pre-computed mtod to avoid the overhead. But this will not resolve the 2MB and 1GB huge = page copy alloc failures. IMHO, I believe in similar lines to other perf application, dma-perf applic= ation should focus on acutal device performance over application application performance. [MB:] OK, Vipin has multiple good arguments for this patch. I am convinced, let= =92s proceed with it. Acked-by: Morten Br=F8rup --_000_MN2PR12MB30850F386E8FC5EE6DC066FF828EAMN2PR12MB3085namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

[AMD Official Use Only - General]


Thank you Morten for= the understanding
From: Morten Br=F8rup <m= b@smartsharesystems.com>
Sent: 12 December 2023 23:39
To: Varghese, Vipin <Vipin.Varghese@amd.com>; Bruce Richardson= <bruce.richardson@intel.com>
Cc: Yigit, Ferruh <Ferruh.Yigit@amd.com>; dev@dpdk.org <dev= @dpdk.org>; stable@dpdk.org <stable@dpdk.org>; honest.jiang@foxmai= l.com <honest.jiang@foxmail.com>; P, Thiyagarajan <Thiyagarajan.P@= amd.com>
Subject: RE: [PATCH] app/dma-perf: replace pktmbuf with mempool obje= cts
 
C= aution: This message originated from an External Source. Use proper = caution when opening attachments, clicking links, or responding.

 

From: Varg= hese, Vipin [mailto:Vipin.Varghese@amd.com]
Sent: Tuesday, 12 December 2023 18.14

Sharing a few critical points based on my= exposure to the dma-perf application below

 

<Snipped>

On Tue, Dec 12, 2023 at 04:16:20PM +0100, Morten Br=F8rup wrote:
> +TO: Bruce, please stop me if I'm completely off track here.
>
> > From: Ferruh Yigit [mailto:ferruh.yigit@amd.com] = Sent: Tuesday, 12
> > December 2023 15.38
> >
> > On 12/12/2023 11:40 AM, Morten Br=F8rup wrote:
> > >> From: Vipin Varghese [mailto:vipin.varghes= e@amd.com] Sent: Tuesday,
> > >> 12 December 2023 11.38
> > >>
> > >> Replace pktmbuf pool with mempool, this allows increase = in MOPS
> > >> especially in lower buffer size. Using Mempool, allows t= o reduce the
> > >> extra CPU cycles.
> > >
> > > I get the point of this change: It tests the performance of = copying
> > raw memory objects using respectively rte_memcpy and DMA, without= the
> > mbuf indirection overhead.
> > >
> > > However, I still consider the existing test relevant: The pe= rformance
> > of copying packets using respectively rte_memcpy and DMA.
> > >
> >
> > This is DMA performance test application and packets are not used= ,
> > using pktmbuf just introduces overhead to the main focus of the > > application.
> >
> > I am not sure if pktmuf selected intentionally for this test
> > application, but I assume it is there because of historical reaso= ns.
>
> I think pktmbuf was selected intentionally, to provide more accurate > results for application developers trying to determine when to use
> rte_memcpy and when to use DMA. Much like the "copy breakpoint&qu= ot; in Linux
> Ethernet drivers is used to determine which code path to take for each=
> received packet.

 

yes Ferruh, this is the= right understanding. In DPDK example we already have 

dma-forward application= which makes use of pktmbuf payload to copy over

new pktmbuf payload are= a. 

 

by moving to mempool, w= e are actually now focusing on source and destination buffers.

This allows to create m= empool objects with 2MB and 1GB src-dst areas. Thus allowing

to focus src to dst cop= y. With pktmbuf we were not able to achieve the same.

 


>
> Most applications will be working with pktmbufs, so these applications=
> will also experience the pktmbuf overhead. Performance testing with th= e
> same overhead as the application will be better to help the applicatio= n
> developer determine when to use rte_memcpy and when to use DMA when > working with pktmbufs.

 

Morten thank you = for the input, but as shared above DPDK example dma-fwd does 

justice to such s= cenario. inline to test-compress-perf & test-crypto-perf IMHO test-dma-= perf

should focus on g= etting best values of dma engine and memcpy comparision.


>
> (Furthermore, for the pktmbuf tests, I wonder if copying performance > could also depend on IOVA mode and RTE_IOVA_IN_MBUF.)
>
> Nonetheless, there may also be use cases where raw mempool objects are=
> being copied by rte_memcpy or DMA, so adding tests for these use cases=
> are useful.
>
>
> @Bruce, you were also deeply involved in the DMA library, and probably=
> have more up-to-date practical experience with it. Am I right that
> pktmbuf overhead in these tests provides more "real life use"= ;-like
> results? Or am I completely off track with my thinking here, i.e. the<= br> > pktmbuf overhead is only noise?
>
I'm actually not that familiar with the dma-test application, so can't
comment on the specific overhead involved here. In the general case, if we<= br> are just talking about the overhead of dereferencing the mbufs then I would=
expect the overhead to be negligible. However, if we are looking to include=
the cost of allocation and freeing of buffers, I'd try to avoid that as it<= br> is a cost that would have to be paid for both SW copies and HW copies, so should not count when calculating offload cost.

 

Bruce, as per tes= t-dma-perf there is no repeated pktmbuf-alloc or pktmbuf-free. =

Hence I disagree = that the overhead discussed for pkmbuf here is not related to alloc and fre= e.

But the cost as p= er my investigation goes into fetching the cacheline and performing mtod on=

each iteration.

/Bruce

I can rewrite the= logic to make use pktmbuf objects by sending the src and dst with pre-comp= uted 

mtod to avoid the= overhead. But this will not resolve the 2MB and 1GB huge page copy alloc f= ailures.

IMHO, I believe i= n similar lines to other perf application, dma-perf application should focu= s on acutal device

performance over = application application performance.

 

[MB:]

OK, Vipin has multipl= e good arguments for this patch. I am convinced, let=92s proceed with it.

 

Acked-by: Morten Br= =F8rup <mb@smartsharesystems.com>

 

--_000_MN2PR12MB30850F386E8FC5EE6DC066FF828EAMN2PR12MB3085namp_--