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 4261441C4D; Thu, 9 Feb 2023 10:11:03 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 22DEC40DF8; Thu, 9 Feb 2023 10:11:03 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 860FF4067B for ; Thu, 9 Feb 2023 10:11:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675933861; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3WHImSP3JK6qWeqVlE6h2mqUrsVw6/eCy6z4wnuoPOo=; b=AOudtqPnzZ0oLxUjtCwvr5RImq7oHELz7Bk7XYARJy9O1sguZr5ut7JyWoJ5YLpkJUJtqD AEkQZhuJzDnnh5YY3kODfudzngoLCYDeGd+IowwbZ83xUdF6ziIZgbBtNhqMp/FAc7qilL vkoPWbY/fZLlGxlA+k7QTGBG6u4rLB0= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-670-uPSiBOCMPyyh8qDfwM5L2A-1; Thu, 09 Feb 2023 04:10:59 -0500 X-MC-Unique: uPSiBOCMPyyh8qDfwM5L2A-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3A1763815EE1; Thu, 9 Feb 2023 09:10:59 +0000 (UTC) Received: from [10.39.208.26] (unknown [10.39.208.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F36F718EC1; Thu, 9 Feb 2023 09:10:57 +0000 (UTC) Message-ID: Date: Thu, 9 Feb 2023 10:10:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v1 13/13] test/bbdev: remove iteration count check To: "Vargas, Hernan" , "dev@dpdk.org" , "gakhil@marvell.com" , "Rix, Tom" Cc: "Chautru, Nicolas" , "Zhang, Qi Z" References: <20230117165023.20567-1-hernan.vargas@intel.com> <20230117165023.20567-14-hernan.vargas@intel.com> <2587fa70-201f-c90f-ae16-2c31cb672cbe@redhat.com> From: Maxime Coquelin In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 2/8/23 21:38, Vargas, Hernan wrote: > Hi Maxime, > > We would like to keep the same signature for validate_dec_op because there are functions such as latency_test_dec that have vector_mask on their signatures and they pass it to validate_dec_op. > Let me know if you'd like to discuss more. I think this is not a valid reason, just simplify latency_test_dec too. Thanks, Maxime > Thanks, > Hernan > > -----Original Message----- > From: Maxime Coquelin > Sent: Tuesday, January 31, 2023 6:36 AM > To: Vargas, Hernan ; dev@dpdk.org; gakhil@marvell.com; Rix, Tom > Cc: Chautru, Nicolas ; Zhang, Qi Z > Subject: Re: [PATCH v1 13/13] test/bbdev: remove iteration count check > > > > On 1/17/23 17:50, Hernan Vargas wrote: >> To make the test compatible with devices that do not support early >> termination, the iteration count assert can be removed. >> >> Signed-off-by: Hernan Vargas >> --- >> app/test-bbdev/test_bbdev_perf.c | 6 +----- >> 1 file changed, 1 insertion(+), 5 deletions(-) >> >> diff --git a/app/test-bbdev/test_bbdev_perf.c >> b/app/test-bbdev/test_bbdev_perf.c >> index 81bf2c8b60..c68d79cf29 100644 >> --- a/app/test-bbdev/test_bbdev_perf.c >> +++ b/app/test-bbdev/test_bbdev_perf.c >> @@ -2290,6 +2290,7 @@ static int >> validate_dec_op(struct rte_bbdev_dec_op **ops, const uint16_t n, >> struct rte_bbdev_dec_op *ref_op, const int vector_mask) >> { >> + RTE_SET_USED(vector_mask); > > Why not just remove vector_mask if it isn't of any use instead of hiding the warning? > >> unsigned int i; >> int ret; >> struct op_data_entries *hard_data_orig = @@ -2299,17 +2300,12 @@ >> validate_dec_op(struct rte_bbdev_dec_op **ops, const uint16_t n, >> struct rte_bbdev_op_turbo_dec *ops_td; >> struct rte_bbdev_op_data *hard_output; >> struct rte_bbdev_op_data *soft_output; >> - struct rte_bbdev_op_turbo_dec *ref_td = &ref_op->turbo_dec; >> >> for (i = 0; i < n; ++i) { >> ops_td = &ops[i]->turbo_dec; >> hard_output = &ops_td->hard_output; >> soft_output = &ops_td->soft_output; >> >> - if (vector_mask & TEST_BBDEV_VF_EXPECTED_ITER_COUNT) >> - TEST_ASSERT(ops_td->iter_count <= ref_td->iter_count, >> - "Returned iter_count (%d) > expected iter_count (%d)", >> - ops_td->iter_count, ref_td->iter_count); >> ret = check_dec_status_and_ordering(ops[i], i, ref_op->status); >> TEST_ASSERT_SUCCESS(ret, >> "Checking status and ordering for decoder failed"); > > Maxime >