DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Chautru, Nicolas" <nicolas.chautru@intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.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 00:18:02 +0000	[thread overview]
Message-ID: <BY5PR11MB4451003A2CE4FF8EC7D702FFF81B9@BY5PR11MB4451.namprd11.prod.outlook.com> (raw)
In-Reply-To: <e4b6f650-b71f-c1da-c432-085e88400fe3@redhat.com>

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?

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  0:18 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 [this message]
2022-12-06 14:46       ` Maxime Coquelin

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=BY5PR11MB4451003A2CE4FF8EC7D702FFF81B9@BY5PR11MB4451.namprd11.prod.outlook.com \
    --to=nicolas.chautru@intel.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=maxime.coquelin@redhat.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).