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 55CFC43BCF; Thu, 7 Mar 2024 14:41:45 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E1FC74067E; Thu, 7 Mar 2024 14:41:44 +0100 (CET) Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by mails.dpdk.org (Postfix) with ESMTP id 331FB40272 for ; Thu, 7 Mar 2024 14:41:42 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.234]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4Tr9Rs2CRsz1vvvL; Thu, 7 Mar 2024 21:40:57 +0800 (CST) Received: from dggpeml500024.china.huawei.com (unknown [7.185.36.10]) by mail.maildlp.com (Postfix) with ESMTPS id 063BD140336; Thu, 7 Mar 2024 21:41:38 +0800 (CST) Received: from [10.67.121.161] (10.67.121.161) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 7 Mar 2024 21:41:37 +0800 Subject: Re: [EXTERNAL] Re: [EXT] Re: [PATCH v2] app/dma-perf: support bi-directional transfer To: Amit Prakash Shukla , Cheng Jiang , Gowrishankar Muthukrishnan CC: "dev@dpdk.org" , Jerin Jacob , Anoob Joseph , Kevin Laatz , Bruce Richardson , Pavan Nikhilesh Bhagavatula References: <20240108082749.1016345-1-amitprakashs@marvell.com> <20240227192601.3932913-1-amitprakashs@marvell.com> <1e4fe21a-8732-779b-0def-938832bdae2d@huawei.com> From: fengchengwen Message-ID: <402af83a-7370-db10-699f-cf1a73ae9ff7@huawei.com> Date: Thu, 7 Mar 2024 21:41:37 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.161] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpeml500024.china.huawei.com (7.185.36.10) 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 Hi Amit, On 2024/3/1 18:59, Amit Prakash Shukla wrote: > Hi Chengwen, > > Please find my reply in-line. > > Thanks, > Amit Shukla > >> Hi Amit, >> >> On 2024/3/1 16:31, Amit Prakash Shukla wrote: >>> Hi Chengwen, >>> >>> If I'm not wrong, your concern was about config file additions and not >>> about the test as such. If the config file is getting complicated and >>> there are better alternatives, we can minimize the config file changes >>> with this patch and just provide minimum functionality as required and >>> leave it open for future changes. For now, I can document the existing >>> behavior in documentation as "Constraints". Similar approach is >>> followed in other application such as ipsec-secgw >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__doc.dpdk.org_guid >>> es_sample-5Fapp-5Fug_ipsec-5Fsecgw.html- >> 23constraints&d=DwICaQ&c=nKjWe >>> >> c2b6R0mOyPaz7xtfQ&r=ALGdXl3fZgFGR69VnJLdSnADun7zLaXG1p5Rs7pXihE >> &m=UXlZ >>> >> 1CWj8uotMMmYQ4e7wtBXj4geBwcMUirlqFw0pZzSlOIIAVjWaPgcaXtni370& >> s=haaehrX >>> QSEG6EFRW8w2sHKUTU75aJX7ML8vM-0mJsAI&e= >> >> Yes, I prefer enable different test just by modify configuration file, and then >> limit the number of entries at the same time. >> >> This commit is bi-direction transfer, it is fixed, maybe later we should test 3/4 >> for mem2dev while 1/4 for dev2mem. > > Agreed. We will add this later after the base functionality is merged. I will send next version with constraints listed. Can I assume next version is good for merge? I suggest do it all at once in [1]. [1] https://patches.dpdk.org/project/dpdk/cover/cover.1709210551.git.gmuthukrishn@marvell.com/ Thanks > >> >> sometime we may need evaluate performance of one dma channel for >> mem2mem, while another channel for mem2dev, we can't do this in current >> implement (because vchan_dev is for all DMA channel). > > We are okay with extending it later. As you said, we are still deciding how the configuration file should look like. > >> >> So I prefer restrict DMA non-mem2mem's config (include >> dir/type/coreid/pfid/vfid/raddr) as the dma device's private configuration. >> >> Thanks >> >>> >>> Constraints: >>> 1. vchan_dev config will be same for all the configured DMA devices. >>> 2. Alternate DMA device will do dev2mem and mem2dev implicitly. >>> Example: >>> xfer_mode=1 >>> vchan_dev=raddr=0x200000000,coreid=1,pfid=2,vfid=3 >>> lcore_dma=lcore10@0000:00:04.2, lcore11@0000:00:04.3, >>> lcore12@0000:00:04.4, lcore13@0000:00:04.5 >>> >>> lcore10@0000:00:04.2, lcore12@0000:00:04.4 will do dev2mem and >> lcore11@0000:00:04.3, lcore13@0000:00:04.5 will do mem2dev. >>> >>> Thanks, >>> Amit Shukla >>> >>>> -----Original Message----- >>>> From: fengchengwen >>>> Sent: Friday, March 1, 2024 7:16 AM >>>> To: Amit Prakash Shukla ; Cheng Jiang >>>> ; Gowrishankar Muthukrishnan >>>> >>>> Cc: dev@dpdk.org; Jerin Jacob ; Anoob Joseph >>>> ; Kevin Laatz ; Bruce >>>> Richardson ; Pavan Nikhilesh Bhagavatula >>>> >>>> Subject: [EXTERNAL] Re: [EXT] Re: [PATCH v2] app/dma-perf: support >>>> bi- directional transfer >>>> >>>> Prioritize security for external emails: Confirm sender and content >>>> safety before clicking links or opening attachments >>>> >>>> --------------------------------------------------------------------- >>>> - >>>> Hi Amit, >>>> >>>> I think this commit will complicated the test, plus futer we may add >>>> more test (e.g. fill) >>>> >>>> I agree Bruce's advise in the [1], let also support "lcore_dma0/1/2", >>>> >>>> User could provide dma info by two way: >>>> 1) lcore_dma=, which seperate each dma with ", ", but a maximum of a >>>> certain number is allowed. >>>> 2) lcore_dma0/1/2/..., each dma device take one line >>>> >>>> [1] https://urldefense.proofpoint.com/v2/url?u=https- >>>> 3A__patchwork.dpdk.org_project_dpdk_patch_20231206112952.1588- >>>> 2D1-2Dvipin.varghese- >>>> >> 40amd.com_&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=ALGdXl3fZgFGR6 >>>> 9VnJLdSnADun7zLaXG1p5Rs7pXihE&m=OwrvdPIi- >>>> >> TQ2UEH3cztfXDzT8YkOB099Pl1mfUzGaq9td0fEWrRBLQQBzAFkjQSU&s=kKin >>>> YsGoNyTxuLEyPJ0LppT17Yq64CvFBtJMirGEISI&e= >>>> >>>> Thanks >>>> >>>> On 2024/2/29 22:03, Amit Prakash Shukla wrote: >>>>> Hi Chengwen, >>>>> >>>>> I liked your suggestion and tried making changes, but encountered >>>>> parsing >>>> issue for CFG files with line greater than CFG_VALUE_LEN=256(current >>>> value set). >>>>> >>>>> There is a discussion on the similar lines in another patch set: >>>> https://urldefense.proofpoint.com/v2/url?u=https- >>>> 3A__patchwork.dpdk.org_project_dpdk_patch_20231206112952.1588- >>>> 2D1-2Dvipin.varghese- >>>> >> 40amd.com_&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=ALGdXl3fZgFGR6 >>>> 9VnJLdSnADun7zLaXG1p5Rs7pXihE&m=OwrvdPIi- >>>> >> TQ2UEH3cztfXDzT8YkOB099Pl1mfUzGaq9td0fEWrRBLQQBzAFkjQSU&s=kKin >>>> YsGoNyTxuLEyPJ0LppT17Yq64CvFBtJMirGEISI&e= . >>>>> >>>>> I believe this patch can be taken as-is and we can come up with the >>>>> solution >>>> when we can increase the CFG_VALUE_LEN as changing CFG_VALUE_LEN in >>>> this release is causing ABI breakage. >>>>> >>>>> Thanks, >>>>> Amit Shukla >>>>> > > >