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 92057423FE; Tue, 17 Jan 2023 17:52:25 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 74AD0410DD; Tue, 17 Jan 2023 17:52:25 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id BD37C4067E for ; Tue, 17 Jan 2023 17:52:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673974342; x=1705510342; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=Lsf2whes8RiR1FjgE8+BiUUMPXSH5Gj99735/UnraE4=; b=FaSKT5YNo0qWRSVZh0F4hBgNdYEJuL2LCSjUIGB15mizEE6NcUPkWIvE sqZSTFUNjxsp+WSvMOzAZL4ptGLtV86mkXddWYS5pXLGU0tJKO/tpD0MW gZ2SSPCmOt8RawgkNyD4R9hk5Rv6SjxtN3FmAY6RjS+tcAZ1hSALOryx5 byhSGtV8PDL+L4YoAAUiw6WZnGtc2sPBB1orCS5wXm2T1NRXLcxGGKUuh 5IgSyXzfw85REk5EUeaFHWw8pSAZxH+a/oQtip53yQ1Wmd0Qu+m9sqajz 2SyZjmNtmzsrEYK//5crPp4mmTFC93zcFHYwWvNZ/wS5NcZadJkEMEKPt A==; X-IronPort-AV: E=McAfee;i="6500,9779,10592"; a="410985161" X-IronPort-AV: E=Sophos;i="5.97,224,1669104000"; d="scan'208";a="410985161" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2023 08:52:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10592"; a="904710905" X-IronPort-AV: E=Sophos;i="5.97,224,1669104000"; d="scan'208";a="904710905" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga006.fm.intel.com with ESMTP; 17 Jan 2023 08:51:59 -0800 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Tue, 17 Jan 2023 08:51:58 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Tue, 17 Jan 2023 08:51:58 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.44) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Tue, 17 Jan 2023 08:51:56 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aNBlp/Cshf5FyA2bCgaY8PvDDmjocLW4ZhXmUwNgESNThPffdaCLDEmubbtUs4rnyfXUGEZ50TZA5USetmUHnfoMO242H39vEx+HEKovQU2bSKAxJKjwzfUl/pCMCd7WZdDMtOpb+b/C70WYPoDC674CifE32SVq2eSEbPeXfN5Un8rg8nBqlWNYYo1Em7r4PD3fSpVLoaA74kVYQGvhT0+GPWwSFr/3nn4bJodlv8Y3CEd8u4vsW4oq5wwT0exVELbc6Ri1Y4WGl7HMfN+GXUzORgNLhQy7fQQnmRmbqqXfiHmlAG8ULSuQ7c6CaRDOUOVrxCIawR2ajxY3/xQ6/g== 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=R2/xi5CjTmpKLsUWBryujS3DBW6DGtz9jbZ8oxOaGmY=; b=QDv2986E/POQqmIYVcAfE2sccpGxm0PFdE8RLaUCXI4QQ1E79buvHbyx4SYBf7PTNDXlOzgANOVaPXcoKGuTPA1PGIG2RAAxqbyFbPNddHLMnKu73JhSBU37z2te96zUmHHxXBEifbriusmuIST3D5+umXXFQmFcdlEz3n5OQa5xtdgFT0qS8Nb9+IsbnYgiMZmmaygW/qVJzo5Fycql4zZ/iSFvXWv9CXSNZjxeB9k4ZP1vCszRT5V0hswarXCfyxqU0pc03yI9tTCBxb5uiv1063KRM4QtY9KSBiRLhBPgLG1q/pa6AEg2sB62MIrWA8gPlaPjQHtLL7UO8pwqCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by MN6PR11MB8170.namprd11.prod.outlook.com (2603:10b6:208:47c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.23; Tue, 17 Jan 2023 16:51:54 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::4d9f:6867:2d53:9ee]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::4d9f:6867:2d53:9ee%7]) with mapi id 15.20.5986.023; Tue, 17 Jan 2023 16:51:54 +0000 Date: Tue, 17 Jan 2023 16:51:46 +0000 From: Bruce Richardson To: Cheng Jiang CC: , , , , , , , Subject: Re: [PATCH v3] app/dma-perf: introduce dma-perf application Message-ID: References: <20221220010619.31829-1-cheng1.jiang@intel.com> <20230117120526.39375-1-cheng1.jiang@intel.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230117120526.39375-1-cheng1.jiang@intel.com> X-ClientProxiedBy: LO2P123CA0032.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600::20) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|MN6PR11MB8170:EE_ X-MS-Office365-Filtering-Correlation-Id: 33464f20-765b-4866-2cac-08daf8ab2302 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: aBqhOrIZml4ojv3GyAhyLatvqwCr9Lqe0PRXESUAEpBstoL2kkNG3NsH3rPkjYY7xdNOp6BelupzTjKt1nV1pRH+vVKz9Vsm74zu3VTecGTwiBKQwLtv3Ov7uxkoQX8R81HqZksVVEfxwdFJnP+m6NW/zdMihwvl6Y4q7+8eO0ZLrj0D+zwIA9ygpMXgLgaO3kJQ9eJe5Ef5uxjjbTDRTlq5mBqwDV4BFOPLn0rWvoYsooolIyxAOvVZ1NNN0k47hfEWCivVFP9YswusYq7dp+ZskDcbvsEM/QEF76qS8VBX9rRsiAgJX5BhDjOeTWvTTFS+qFhPFv8vgsZbTBnUGEGfjR61pzGuOj9hawxAubxfSRgic7gEauAt6AEJx6N7BT5GdafdNcGFzpagmi4+C5UX9M/TfjzZ0ffotB+uWONLeaeOfT5pXIZUU7urk4vwuiv+pS+AeHWkN/gsyO6ZkxjIXrNpCOFnFVzUCJoGlocoaJn3zPsAzLDbeSfPe8DQ3uGJMKl2HywrEP4tASkytQQ8o+xMqj2x+aHNFW7Vez4kSp7MURj6JwKRzfSfsFqpPCD8rxRv+P96MLhAYZWp5Dp8akEXiZrL9QYlPpSfvV5EXRpbuH2ys3cvyROOt88lrgM3j607gRzYPiU3E5oJug== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(346002)(39860400002)(136003)(396003)(376002)(366004)(451199015)(38100700002)(83380400001)(82960400001)(86362001)(8676002)(5660300002)(8936002)(66556008)(6862004)(44832011)(66476007)(66946007)(2906002)(4326008)(478600001)(41300700001)(26005)(6506007)(186003)(107886003)(66574015)(6512007)(6636002)(6486002)(316002)(6666004); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?p8bAN02+lCm+Pd4fnHFanj6cEhGV8OBdwKHLoJON848iH+/wXzrzOLYWzT?= =?iso-8859-1?Q?bWYwLuuNK8ChKZ5wJmTXcAD5NTadrNlwLqEBWS6q5Tna3owWC8z20+6YbH?= =?iso-8859-1?Q?WQ1FP4t+Cuia1Gnh0dhDbSDvUx068ySoOevaFxVi6Uh+uDKbgp8GRkbG1E?= =?iso-8859-1?Q?Y1V4xA1YGZS45Xf+uwwvjLDP6pgHy1trIITnZ0rvzmSXyESzwaEEkSWMrY?= =?iso-8859-1?Q?YBmicOBke/PfqA/JxwKsv8DCfGwgwqukpOe2Kzs7r8YUYyLnn82AaSePHT?= =?iso-8859-1?Q?VFVZzfKow1cEjzWLuVJCo+bNn+6gSGJ4/yUvcR5l092J0UlEAbafg9EMAw?= =?iso-8859-1?Q?6STWc7Gbi36ePZJlLT8JeRtaEBLPC0tAur7Fwy7tYYoslRTBTpgZiEgrw2?= =?iso-8859-1?Q?4kLX54CzNOYQI0JqhtlvPPeduY7Atq8PiU1fURvBQ5oJGVAqrC042sEubd?= =?iso-8859-1?Q?N6kzkwhlYf3VSDbDKaeuIcWJpiuljwvEnvwc+X3Y4eMvf96uKxFF73oqyL?= =?iso-8859-1?Q?tPJqyN+Ni9Dg/Ra56q9e8nDS0zyVcvp5wQb97JNpgQ6po5BK7C+jcEK/eY?= =?iso-8859-1?Q?XOyqcIKd3LAt8O9vNt3wNKUFTBSaWmFZAjIU+wDbK1W4UVBRNuFHH2MEtW?= =?iso-8859-1?Q?GLJtp3buea2PaSCZgYFV9sQwayQT3Y9i3wU5yQfAPcnHG3cijhLQqWiUWe?= =?iso-8859-1?Q?+z3GXz30pmzUU++woZX0cL5ewBxmkhJmy+POR77Iksj97ZBjRitryjPsbV?= =?iso-8859-1?Q?medZT3aP0pmTFWfrx33Ut4cQ36QWrzUE5SpLr3+QTo7BTvMC/P3pIPd59o?= =?iso-8859-1?Q?V4CrXGbmb9aqQARJxy8McVWP5kZteZz8JJh9BumyJOwvS2Cl49JG/ApbbA?= =?iso-8859-1?Q?Q4Vs+2dcWL/KDZOGSrVS8JvsQNggO1ifZGaFwjlO0bgO08/T5F7Fr88sC4?= =?iso-8859-1?Q?CthUd6Yq0M/3NX+nETDnLf4+bkRiTLIUB5zDFT57knRDTPO2rg07Uvpy3H?= =?iso-8859-1?Q?tlUqvxxgwcBmNFfNYQ9bzFTGr4Eo5tc1Rie0Q2GI75nP+WUqwu9sYqz4eL?= =?iso-8859-1?Q?mwVHuAe4WKazDu0j5N41V/EePCBw//l+HDMh8axcMKLFQ9Vvzmk0rv5EPW?= =?iso-8859-1?Q?E1F5K6YfbiK5+Lix0p8foxXC/PnTrZjRPIcUGNMp0LcSs8mgknk4np3mlD?= =?iso-8859-1?Q?CgiW8duHml8Ox/FkGVGppDJ91P6dVWCgiyLr/k6BPmIvfhxtsPELcwD6XM?= =?iso-8859-1?Q?Q8IrL137oVDZFRiw50rXQAoyV47IuoIq7yBrn9rach9PNAI9JXo5ln0SUl?= =?iso-8859-1?Q?9GMW/tED5GJtvXA7cnlN0KxZeqyhskZGQ48YihRDFIT7GjxZwcSs5zPy1g?= =?iso-8859-1?Q?1CZTbDYXR3dKDI3o9qz3747SSdx0gcQ4R3A6trD7HcoDGLpnaIB+xyt0Az?= =?iso-8859-1?Q?eJ21t5LjXwe9ZTsVCfFcE3DuKtPVSnDj1MFg9maV6lKqWtbDS5vB0B2ehK?= =?iso-8859-1?Q?euP79Gcuyw4iuTl5COWp8rW8u66DwwuKOQO3G0xyyJRxetpq3QtI0/Q8MD?= =?iso-8859-1?Q?ZFJk2Z3M5RDmNv2XDFVlWe4aArZpIqbVOsNS/q/WBgk8tcEUPLUi/uq3U7?= =?iso-8859-1?Q?/6XPqoytjmIUahcKTudQTCv+VBoUgVfk7PgqMLCcQYRXjip1M4Uj/ZOw?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 33464f20-765b-4866-2cac-08daf8ab2302 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2023 16:51:53.9600 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: BW1b1rMt2ZO0ian5Puy4myu/ke6exZxmOR2+nJOJFSHT4IAvtWx4sItGk5AtQBjQXy/xRQbwiG+8pOOHLAHEWwKRoS2GPc+bEZseiX23NuY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR11MB8170 X-OriginatorOrg: intel.com 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 Tue, Jan 17, 2023 at 12:05:26PM +0000, Cheng Jiang wrote: > There are many high-performance DMA devices supported in DPDK now, and > these DMA devices can also be integrated into other modules of DPDK as > accelerators, such as Vhost. Before integrating DMA into applications, > developers need to know the performance of these DMA devices in various > scenarios and the performance of CPUs in the same scenario, such as > different buffer lengths. Only in this way can we know the target > performance of the application accelerated by using them. This patch > introduces a high-performance testing tool, which supports comparing the > performance of CPU and DMA in different scenarios automatically with a > pre-set config file. Memory Copy performance test are supported for now. > > Signed-off-by: Cheng Jiang > Signed-off-by: Jiayu Hu > Signed-off-by: Yuan Wang > Acked-by: Morten Brørup > --- More input based off trying running the application, including some thoughts on the testing methodology below. > +static void > +output_result(uint8_t scenario_id, uint32_t lcore_id, uint16_t dev_id, uint64_t ave_cycle, > + uint32_t buf_size, uint32_t nr_buf, uint32_t memory, > + float bandwidth, uint64_t ops, bool is_dma) > +{ > + if (is_dma) > + printf("lcore %u, DMA %u:\n" > + "average cycles: %" PRIu64 "," > + " buffer size: %u, nr_buf: %u," > + " memory: %uMB, frequency: %" PRIu64 ".\n", > + lcore_id, > + dev_id, > + ave_cycle, > + buf_size, > + nr_buf, > + memory, > + rte_get_timer_hz()); > + else > + printf("lcore %u\n" > + "average cycles: %" PRIu64 "," > + " buffer size: %u, nr_buf: %u," > + " memory: %uMB, frequency: %" PRIu64 ".\n", > + lcore_id, > + ave_cycle, > + buf_size, > + nr_buf, > + memory, > + rte_get_timer_hz()); > + The term "average cycles" is unclear here - is it average cycles per test iteration, or average cycles per buffer copy? > + printf("Average bandwidth: %.3lfGbps, OPS: %" PRIu64 "\n", bandwidth, ops); > + > + > +static inline void > +do_dma_mem_copy(uint16_t dev_id, uint32_t nr_buf, uint16_t kick_batch, uint32_t buf_size, > + uint16_t mpool_iter_step, struct rte_mbuf **srcs, struct rte_mbuf **dsts) > +{ > + int64_t async_cnt = 0; > + int nr_cpl = 0; > + uint32_t index; > + uint16_t offset; > + uint32_t i; > + > + for (offset = 0; offset < mpool_iter_step; offset++) { > + for (i = 0; index = i * mpool_iter_step + offset, index < nr_buf; i++) { > + if (unlikely(rte_dma_copy(dev_id, > + 0, > + srcs[index]->buf_iova + srcs[index]->data_off, > + dsts[index]->buf_iova + dsts[index]->data_off, > + buf_size, > + 0) < 0)) { > + rte_dma_submit(dev_id, 0); > + while (rte_dma_burst_capacity(dev_id, 0) == 0) { > + nr_cpl = rte_dma_completed(dev_id, 0, MAX_DMA_CPL_NB, > + NULL, NULL); > + async_cnt -= nr_cpl; > + } > + if (rte_dma_copy(dev_id, > + 0, > + srcs[index]->buf_iova + srcs[index]->data_off, > + dsts[index]->buf_iova + dsts[index]->data_off, > + buf_size, > + 0) < 0) { > + printf("enqueue fail again at %u\n", index); > + printf("space:%d\n", rte_dma_burst_capacity(dev_id, 0)); > + rte_exit(EXIT_FAILURE, "DMA enqueue failed\n"); > + } > + } > + async_cnt++; > + > + /** > + * When '&' is used to wrap an index, mask must be a power of 2. > + * That is, kick_batch must be 2^n. > + */ > + if (unlikely((async_cnt % kick_batch) == 0)) { > + rte_dma_submit(dev_id, 0); > + /* add a poll to avoid ring full */ > + nr_cpl = rte_dma_completed(dev_id, 0, MAX_DMA_CPL_NB, NULL, NULL); > + async_cnt -= nr_cpl; > + } > + } > + > + rte_dma_submit(dev_id, 0); > + while (async_cnt > 0) { > + nr_cpl = rte_dma_completed(dev_id, 0, MAX_DMA_CPL_NB, NULL, NULL); > + async_cnt -= nr_cpl; > + } I have a couple of concerns about the methodology for testing the HW DMA performance. For example, the inclusion of that final block means that we are including the latency of the copy operation in the result. If the objective of the test application is to determine if it is cheaper for software to offload a copy operation to HW or do it in SW, then the primary concern is the HW offload cost. That offload cost should remain constant irrespective of the size of the copy - since all you are doing is writing a descriptor and reading a completion result. However, seeing the results of running the app, I notice that the reported average cycles increases as the packet size increases, which would tend to indicate that we are not giving a realistic measurement of offload cost. The trouble then becomes how to do so in a more realistic manner. The most accurate way I can think of in a unit test like this is to offload entries to the device and measure the cycles taken there. Then wait until such time as all copies are completed (to eliminate the latency time, which in a real-world case would be spent by a core doing something else), and then do a second measurement of the time taken to process all the completions. In the same way as for a SW copy, any time not spent in memcpy is not copy time, for HW copies any time spent not writing descriptors or reading completions is not part of the offload cost. That said, doing the above is still not fully realistic, as a real-world app will likely still have some amount of other overhead, for example, polling occasionally for completions in between doing other work (though one would expect this to be relatively cheap). Similarly, if the submission queue fills, the app may have to delay waiting for space to submit jobs, and therefore see some of the HW copy latency. Therefore, I think the most realistic way to measure this is to look at the rate of operations while processing is being done in the middle of the test. For example, if we have a simple packet processing application, running the application just doing RX and TX and measuring the rate allows us to determine the basic packet I/O cost. Adding in an offload to HW for each packet and again measuring the rate, will then allow us to compute the true offload copy cost of the operation, and should give us a number that remains flat even as packet size increases. For previous work done on vhost with DMA acceleration, I believe we saw exactly that - while SW PPS reduced as packet size increased, with HW copies the PPS remained constant even as packet size increased. The challenge to my mind, is therefore how to implement this in a suitable unit-test style way, to fit into the framework you have given here. I would suggest that the actual performance measurement needs to be done - not on a total time - but on a fixed time basis within each test. For example, when doing HW copies, 1ms into each test run, we need to snapshot the completed entries, and then say 1ms later measure the number that have been completed since. In this way, we avoid the initial startup latency while we wait for jobs to start completing, and we avoid the final latency as we await the last job to complete. We would also include time for some potentially empty polls, and if a queue size is too small see that reflected in the performance too. Thoughts, input from others? /Bruce