DPDK patches and discussions
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Chautru, Nicolas" <nicolas.chautru@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"gakhil@marvell.com" <gakhil@marvell.com>
Cc: "Vargas, Hernan" <hernan.vargas@intel.com>,
	"Vipin.Varghese@amd.com" <Vipin.Varghese@amd.com>,
	"Mcnamara, John" <john.mcnamara@intel.com>,
	"Ferruh.Yigit@amd.com" <Ferruh.Yigit@amd.com>,
	"Clinton.France@amd.com" <Clinton.France@amd.com>
Subject: Re: [PATCH v1 2/2] test/bbdev: fix build issue with optional build flag
Date: Tue, 6 Dec 2022 15:46:57 +0100	[thread overview]
Message-ID: <341c09aa-409b-b3af-6b9b-1b5032ade35d@redhat.com> (raw)
In-Reply-To: <BY5PR11MB4451003A2CE4FF8EC7D702FFF81B9@BY5PR11MB4451.namprd11.prod.outlook.com>

Hi Nicolas,

On 12/6/22 01:18, Chautru, Nicolas wrote:
> Hi Maxime,
> 
>> -----Original Message-----
>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Sent: Thursday, November 24, 2022 12:09 PM
>> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
>> thomas@monjalon.net; gakhil@marvell.com
>> Cc: Vargas, Hernan <hernan.vargas@intel.com>; Vipin.Varghese@amd.com;
>> Mcnamara, John <john.mcnamara@intel.com>; Ferruh.Yigit@amd.com;
>> Clinton.France@amd.com
>> Subject: Re: [PATCH v1 2/2] test/bbdev: fix build issue with optional build flag
>>
>> Hi Nicolas,
>>
>> On 11/24/22 17:06, Nicolas Chautru wrote:
>>> Missing implementation for offload test with FFT.
>>> Only build when the optional build flag RTE_BBDEV_OFFLOAD_COST is set.
>>>
>>> Fixes: 0acdb9866756 ("test/bbdev: add FFT operations cases")
>>>
>>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
>>> ---
>>>    app/test-bbdev/test_bbdev_perf.c | 82
>> ++++++++++++++++++++++++++++++++
>>>    1 file changed, 82 insertions(+)
>>>
>>> diff --git a/app/test-bbdev/test_bbdev_perf.c
>>> b/app/test-bbdev/test_bbdev_perf.c
>>> index 1859952901..b2e536b5e3 100644
>>> --- a/app/test-bbdev/test_bbdev_perf.c
>>> +++ b/app/test-bbdev/test_bbdev_perf.c
>>> @@ -4940,6 +4940,88 @@ get_bbdev_queue_stats(uint16_t dev_id,
>> uint16_t queue_id,
>>>    	return 0;
>>>    }
>>>
>>> +static int
>>> +offload_latency_test_fft(struct rte_mempool *mempool, struct
>> test_buffers *bufs,
>>> +		struct rte_bbdev_fft_op *ref_op, uint16_t dev_id,
>>> +		uint16_t queue_id, const uint16_t num_to_process,
>>> +		uint16_t burst_sz, struct test_time_stats *time_st) {
>>> +	int i, dequeued, ret;
>>> +	struct rte_bbdev_fft_op *ops_enq[MAX_BURST],
>> *ops_deq[MAX_BURST];
>>> +	uint64_t enq_start_time, deq_start_time;
>>> +	uint64_t enq_sw_last_time, deq_last_time;
>>> +	struct rte_bbdev_stats stats;
>>> +
>>> +	for (i = 0, dequeued = 0; dequeued < num_to_process; ++i) {
>>> +		uint16_t enq = 0, deq = 0;
>>> +
>>> +		if (unlikely(num_to_process - dequeued < burst_sz))
>>> +			burst_sz = num_to_process - dequeued;
>>> +
>>> +		rte_bbdev_fft_op_alloc_bulk(mempool, ops_enq, burst_sz);
>>
>> It might be safer to check for error.
> 
> We don’t check for error on the _op_alloc_bulk() for any of the other offload test functions. This could be changed through an independent patchset.
> Are you okay to apply as is on the next-baseband subtree? Or you prefer a v2 with an additional commit now for all these functions?

Both options would be fine to me as long as it is fixed for all the
similar functions.

Thanks,
Maxime

> 
> Thanks
> Nic
> 
>>
>> Given how late we are in the release, and also because it is in the test
>> application, I'm fine if the fix is done in next release.
>>
>> Other than that, it looks good to me:
>> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>>
>> Thanks,
>> Maxime
> 


      reply	other threads:[~2022-12-06 14:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-24 16:06 [PATCH v1 0/2] test/bbdev: fix build issues " Nicolas Chautru
2022-11-24 16:06 ` [PATCH v1 1/2] test/bbdev: fix build issue " Nicolas Chautru
2022-11-24 20:09   ` Maxime Coquelin
2022-11-24 16:06 ` [PATCH v1 2/2] " Nicolas Chautru
2022-11-24 20:09   ` Maxime Coquelin
2022-12-06  0:18     ` Chautru, Nicolas
2022-12-06 14:46       ` Maxime Coquelin [this message]

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=341c09aa-409b-b3af-6b9b-1b5032ade35d@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=Clinton.France@amd.com \
    --cc=Ferruh.Yigit@amd.com \
    --cc=Vipin.Varghese@amd.com \
    --cc=dev@dpdk.org \
    --cc=gakhil@marvell.com \
    --cc=hernan.vargas@intel.com \
    --cc=john.mcnamara@intel.com \
    --cc=nicolas.chautru@intel.com \
    --cc=thomas@monjalon.net \
    /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).