From: "Chautru, Nicolas" <nicolas.chautru@intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>,
"Vargas, Hernan" <hernan.vargas@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"gakhil@marvell.com" <gakhil@marvell.com>,
"Rix, Tom" <trix@redhat.com>
Cc: "Zhang, Qi Z" <qi.z.zhang@intel.com>
Subject: RE: [PATCH v1 09/13] test/bbdev: bbdev-test cannot compare some scenarios
Date: Mon, 13 Feb 2023 19:40:31 +0000 [thread overview]
Message-ID: <BY5PR11MB4451F9237D8A5EC7510CB841F8DD9@BY5PR11MB4451.namprd11.prod.outlook.com> (raw)
In-Reply-To: <18538815-2aa4-df1d-b6a0-df555872ff26@redhat.com>
Hi Maxime,
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Tuesday, January 31, 2023 4:16 AM
> To: Vargas, Hernan <hernan.vargas@intel.com>; dev@dpdk.org;
> gakhil@marvell.com; Rix, Tom <trix@redhat.com>
> Cc: Chautru, Nicolas <nicolas.chautru@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>
> Subject: Re: [PATCH v1 09/13] test/bbdev: bbdev-test cannot compare some
> scenarios
>
>
>
> On 1/17/23 17:50, Hernan Vargas wrote:
> > Updating logic for compression usecases.
> >
> > Signed-off-by: Hernan Vargas <hernan.vargas@intel.com>
> > ---
> > app/test-bbdev/test_bbdev_perf.c | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/app/test-bbdev/test_bbdev_perf.c
> > b/app/test-bbdev/test_bbdev_perf.c
> > index fdf7a28ba2..3b2578baf6 100644
> > --- a/app/test-bbdev/test_bbdev_perf.c
> > +++ b/app/test-bbdev/test_bbdev_perf.c
> > @@ -2143,12 +2143,17 @@ validate_op_harq_chain(struct
> rte_bbdev_op_data *op,
> > total_data_size += orig_op->segments[i].length;
> >
> > TEST_ASSERT(orig_op->segments[i].length <
> > - (uint32_t)(data_len + 64),
> > + (uint32_t)(data_len + 256),
>
> Where is that value coming from?
> It lacks explanations in my opinion, and the patch looks like a fix but is not
> tagged as one.
This is a tolerance as different implementations have different assumptions with regards to the HARQ size explicitly stored in memory (some data may be optimized out or having different alignment assumptions).
Hence the check includes some tolerance specific to that buffer. That tolerance is extended to cover different implementations.
An #define will be used now instead of a magic number HARQ_MEM_TOLERANCE
I don’t believe it is critical to be backported. Still it would not harm to add the fix tag.
Thanks
>
> > "Length of segment differ in original (%u) and
> filled (%u) op",
> > orig_op->segments[i].length, data_len);
> > harq_orig = (int8_t *) orig_op->segments[i].addr;
> > harq_out = rte_pktmbuf_mtod_offset(m, int8_t *, offset);
> >
> > + /* Cannot compare HARQ output data for such cases */
> > + if ((ldpc_llr_decimals > 1) && ((ops_ld->op_flags &
> RTE_BBDEV_LDPC_LLR_COMPRESSION)
> > + || (ops_ld->op_flags &
> RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION)))
> > + break;
> > +
> > if (!(ldpc_cap_flags &
> >
> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS
> > ) || (ops_ld->op_flags &
> > @@ -2224,7 +2229,7 @@ validate_op_harq_chain(struct
> rte_bbdev_op_data
> > *op,
> >
> > /* Validate total mbuf pkt length */
> > uint32_t pkt_len = rte_pktmbuf_pkt_len(op->data) - op->offset;
> > - TEST_ASSERT(total_data_size < pkt_len + 64,
> > + TEST_ASSERT(total_data_size < pkt_len + 256,
> > "Length of data differ in original (%u) and filled (%u)
> op",
> > total_data_size, pkt_len);
> >
next prev parent reply other threads:[~2023-02-13 19:40 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 16:50 [PATCH v1 00/13] test/bbdev: changes for 23.03 Hernan Vargas
2023-01-17 16:50 ` [PATCH v1 01/13] test/bbdev: fix seg fault for non supported HARQ len Hernan Vargas
2023-01-31 9:20 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 02/13] test/bbdev: refactor TB throughput report Hernan Vargas
2023-01-31 9:48 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 03/13] test/bbdev: add timeout for latency tests Hernan Vargas
2023-01-31 10:02 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 04/13] test/bbdev: early termination not explicit set Hernan Vargas
2023-01-31 10:04 ` Maxime Coquelin
2023-02-10 17:15 ` Vargas, Hernan
2023-02-20 15:38 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 05/13] test/bbdev: report device status in bbdev-test Hernan Vargas
2023-01-31 10:05 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 06/13] test/bbdev: log capture from queue stop Hernan Vargas
2023-01-31 10:07 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 07/13] test/bbdev: add support for BLER for 4G Hernan Vargas
2023-01-31 10:20 ` Maxime Coquelin
2023-02-13 20:59 ` Vargas, Hernan
2023-02-20 15:43 ` Maxime Coquelin
2023-02-22 21:55 ` Vargas, Hernan
2023-02-23 8:26 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 08/13] test/bbdev: extend support for large TB Hernan Vargas
2023-01-31 11:29 ` Maxime Coquelin
2023-02-13 20:20 ` Vargas, Hernan
2023-02-20 15:40 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 09/13] test/bbdev: bbdev-test cannot compare some scenarios Hernan Vargas
2023-01-31 12:15 ` Maxime Coquelin
2023-02-13 19:40 ` Chautru, Nicolas [this message]
2023-01-17 16:50 ` [PATCH v1 10/13] test/bbdev: adjustment for soft output Hernan Vargas
2023-01-31 12:25 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 11/13] test/bbdev: expose warning counters Hernan Vargas
2023-01-31 12:26 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 12/13] test/bbdev: remove check for invalid opaque data Hernan Vargas
2023-01-31 12:33 ` Maxime Coquelin
2023-01-17 16:50 ` [PATCH v1 13/13] test/bbdev: remove iteration count check Hernan Vargas
2023-01-31 12:35 ` Maxime Coquelin
2023-02-08 20:38 ` Vargas, Hernan
2023-02-09 9:10 ` Maxime Coquelin
2023-02-09 16:59 ` Chautru, Nicolas
2023-02-10 14:01 ` Maxime Coquelin
2023-02-10 18:11 ` Chautru, Nicolas
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=BY5PR11MB4451F9237D8A5EC7510CB841F8DD9@BY5PR11MB4451.namprd11.prod.outlook.com \
--to=nicolas.chautru@intel.com \
--cc=dev@dpdk.org \
--cc=gakhil@marvell.com \
--cc=hernan.vargas@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=qi.z.zhang@intel.com \
--cc=trix@redhat.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).