DPDK patches and discussions
 help / color / mirror / Atom feed
From: fengchengwen <fengchengwen@huawei.com>
To: Amit Prakash Shukla <amitprakashs@marvell.com>,
	Cheng Jiang <honest.jiang@foxmail.com>,
	Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Jerin Jacob <jerinj@marvell.com>,
	Anoob Joseph <anoobj@marvell.com>,
	Kevin Laatz <kevin.laatz@intel.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>
Subject: Re: [EXTERNAL] Re: [EXT] Re: [PATCH v2] app/dma-perf: support bi-directional transfer
Date: Fri, 1 Mar 2024 17:30:12 +0800	[thread overview]
Message-ID: <b0f6ee02-f777-fc45-f132-1b6b474ea80a@huawei.com> (raw)
In-Reply-To: <PH0PR18MB51675DB53BCF502944C7ECD7C85E2@PH0PR18MB5167.namprd18.prod.outlook.com>

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://doc.dpdk.org/guides/sample_app_ug/ipsec_secgw.html#constraints

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.

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).

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 <fengchengwen@huawei.com>
>> Sent: Friday, March 1, 2024 7:16 AM
>> To: Amit Prakash Shukla <amitprakashs@marvell.com>; Cheng Jiang
>> <honest.jiang@foxmail.com>; Gowrishankar Muthukrishnan
>> <gmuthukrishn@marvell.com>
>> Cc: dev@dpdk.org; Jerin Jacob <jerinj@marvell.com>; Anoob Joseph
>> <anoobj@marvell.com>; Kevin Laatz <kevin.laatz@intel.com>; Bruce
>> Richardson <bruce.richardson@intel.com>; Pavan Nikhilesh Bhagavatula
>> <pbhagavatula@marvell.com>
>> 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
>>>
>>>> -----Original Message-----
>>>> From: Amit Prakash Shukla
>>>> Sent: Wednesday, February 28, 2024 3:08 PM
>>>> To: fengchengwen <fengchengwen@huawei.com>; Cheng Jiang
>>>> <honest.jiang@foxmail.com>; Gowrishankar Muthukrishnan
>>>> <gmuthukrishn@marvell.com>
>>>> Cc: dev@dpdk.org; Jerin Jacob <jerinj@marvell.com>; Anoob Joseph
>>>> <anoobj@marvell.com>; Kevin Laatz <kevin.laatz@intel.com>; Bruce
>>>> Richardson <bruce.richardson@intel.com>; Pavan Nikhilesh Bhagavatula
>>>> <pbhagavatula@marvell.com>
>>>> Subject: RE: [EXT] Re: [PATCH v2] app/dma-perf: support
>>>> bi-directional transfer
>>>>
>>>> Hi Chengwen,
>>>>
>>>> Please see my reply in-line.
>>>>
>>>> Thanks
>>>> Amit Shukla
>>>>
>>>>> -----Original Message-----
>>>>> From: fengchengwen <fengchengwen@huawei.com>
>>>>> Sent: Wednesday, February 28, 2024 12:34 PM
>>>>> To: Amit Prakash Shukla <amitprakashs@marvell.com>; Cheng Jiang
>>>>> <honest.jiang@foxmail.com>; Gowrishankar Muthukrishnan
>>>>> <gmuthukrishn@marvell.com>
>>>>> Cc: dev@dpdk.org; Jerin Jacob <jerinj@marvell.com>; Anoob Joseph
>>>>> <anoobj@marvell.com>; Kevin Laatz <kevin.laatz@intel.com>; Bruce
>>>>> Richardson <bruce.richardson@intel.com>; Pavan Nikhilesh Bhagavatula
>>>>> <pbhagavatula@marvell.com>
>>>>> Subject: [EXT] Re: [PATCH v2] app/dma-perf: support bi-directional
>>>>> transfer
>>>>>
>>>>> External Email
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> --
>>>>> Hi Amit and Gowrishankar,
>>>>>
>>>>> It's nature to support multiple dmadev test in one testcase, and the
>>>>> original framework supports it.
>>>>> But it seem we both complicated it when adding support for non-
>>>> mem2mem
>>>>> dma test.
>>>>>
>>>>> The new added "direction" and "vchan_dev" could treat as the
>>>>> dmadev's private configure, some thing like:
>>>>>
>>>>>
>>>>
>> lcore_dma=lcore10@0000:00:04.2,vchan=0,dir=mem2dev,devtype=pcie,radd
>>>>> r=xxx,coreid=1,pfid=2,vfid=3
>>>>>
>>>>> then this bi-directional could impl only with config:
>>>>>
>>>>>
>>>>
>> lcore_dma=lcore10@0000:00:04.2,dir=mem2dev,devtype=pcie,raddr=xxx,cor
>>>>> eid=1,pfid=2,vfid=3,
>>>>>
>>>>
>> lcore11@0000:00:04.3,dir=dev2mem,devtype=pcie,raddr=xxx,coreid=1,pfid
>>>> =
>>>>> 2,vfid=3
>>>>> so that the lcore10 will do mem2dev with device 0000:00:04.2, while
>>>>> lcore11 will do dev2mem with device 0000:00:04.3.
>>>>
>>>> Thanks for the suggestion. I will make the suggested changes and send
>>>> the next version.

  reply	other threads:[~2024-03-01  9:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08  8:27 [PATCH] " Amit Prakash Shukla
2024-02-21  6:24 ` fengchengwen
2024-02-27  9:53   ` [EXT] " Amit Prakash Shukla
2024-02-27 19:26 ` [PATCH v2] " Amit Prakash Shukla
2024-02-28  7:03   ` fengchengwen
2024-02-28  9:38     ` [EXT] " Amit Prakash Shukla
2024-02-29 14:03       ` Amit Prakash Shukla
2024-03-01  1:46         ` fengchengwen
2024-03-01  8:31           ` [EXTERNAL] " Amit Prakash Shukla
2024-03-01  9:30             ` fengchengwen [this message]
2024-03-01 10:59               ` Amit Prakash Shukla
2024-03-07 13:41                 ` fengchengwen
2024-02-29 14:14   ` [PATCH v3] " Amit Prakash Shukla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b0f6ee02-f777-fc45-f132-1b6b474ea80a@huawei.com \
    --to=fengchengwen@huawei.com \
    --cc=amitprakashs@marvell.com \
    --cc=anoobj@marvell.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=gmuthukrishn@marvell.com \
    --cc=honest.jiang@foxmail.com \
    --cc=jerinj@marvell.com \
    --cc=kevin.laatz@intel.com \
    --cc=pbhagavatula@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).