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 89C0A41D8F; Mon, 27 Feb 2023 10:44:52 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 23A6040A7D; Mon, 27 Feb 2023 10:44:52 +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 BE419400D5 for ; Mon, 27 Feb 2023 10:44:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677491090; 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=BzUFBWnjnk8WDruIGkcLxDs+fobKieQgguFuenvUn8c=; b=K7n3n8BBQiTPws/oGzWZgcl0QN41UEjprGqfkRFKnq++3Q+wKpQ80iFb5HhGhaLs0jmVuO Xqm7VAXq/WogiBlpNa4UbURVEYU+ANw24fsq7b3PWahdMShHbhwEHO60xc80r84ovM64BS CaxgoAYbQ/a5YYZP6MDijTqBFRuyVY8= 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-30-EndMF7TbOK2QzI67G9C_RA-1; Mon, 27 Feb 2023 04:44:47 -0500 X-MC-Unique: EndMF7TbOK2QzI67G9C_RA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A9FFC3C0E202; Mon, 27 Feb 2023 09:44:46 +0000 (UTC) Received: from [10.45.242.42] (unknown [10.45.242.42]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C63E040C6EC4; Mon, 27 Feb 2023 09:44:44 +0000 (UTC) Message-ID: <64ba8d62-8a4b-5c0b-0a41-246b61452cee@redhat.com> Date: Mon, 27 Feb 2023 10:44:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 To: "Vargas, Hernan" , "dev@dpdk.org" , "gakhil@marvell.com" , "Rix, Tom" Cc: "Chautru, Nicolas" , "Zhang, Qi Z" References: <20230215170949.60569-1-hernan.vargas@intel.com> <20230215170949.60569-5-hernan.vargas@intel.com> <72158d97-b9ce-724b-b5bc-df8202657da0@redhat.com> <1eafd7b3-3d12-6e42-31af-378ec94a39dd@redhat.com> From: Maxime Coquelin Subject: Re: [PATCH v2 04/16] test/bbdev: add timeout for latency tests In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 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/24/23 17:59, Vargas, Hernan wrote: > Hi Maxime, > >> -----Original Message----- >> From: Maxime Coquelin >> Sent: Thursday, February 23, 2023 2:32 AM >> To: Vargas, Hernan ; dev@dpdk.org; >> gakhil@marvell.com; Rix, Tom >> Cc: Chautru, Nicolas ; Zhang, Qi Z >> >> Subject: Re: [PATCH v2 04/16] test/bbdev: add timeout for latency tests >> >> >> >> On 2/22/23 22:13, Vargas, Hernan wrote: >>> Hi Maxime, >>> >>>> -----Original Message----- >>>> From: Maxime Coquelin >>>> Sent: Monday, February 20, 2023 10:33 AM >>>> To: Vargas, Hernan ; dev@dpdk.org; >>>> gakhil@marvell.com; Rix, Tom >>>> Cc: Chautru, Nicolas ; Zhang, Qi Z >>>> >>>> Subject: Re: [PATCH v2 04/16] test/bbdev: add timeout for latency >>>> tests >>>> >>>> >>>> >>>> On 2/15/23 18:09, Hernan Vargas wrote: >>>>> Add a timeout to force exit the latency tests in case dequeue never >>>>> happens. >>>>> >>>>> Signed-off-by: Hernan Vargas >>>>> --- >>>>> app/test-bbdev/test_bbdev_perf.c | 24 +++++++++++++++++++----- >>>>> 1 file changed, 19 insertions(+), 5 deletions(-) >>>>> >>>>> diff --git a/app/test-bbdev/test_bbdev_perf.c >>>>> b/app/test-bbdev/test_bbdev_perf.c >>>>> index 19b9a5b119..dede0f900e 100644 >>>>> --- a/app/test-bbdev/test_bbdev_perf.c >>>>> +++ b/app/test-bbdev/test_bbdev_perf.c >>>>> @@ -26,6 +26,7 @@ >>>>> >>>>> #define MAX_QUEUES RTE_MAX_LCORE >>>>> #define TEST_REPETITIONS 100 >>>>> +#define TIME_OUT_POLL 1e8 >>>>> #define WAIT_OFFLOAD_US 1000 >>>>> >>>>> #ifdef RTE_BASEBAND_FPGA_LTE_FEC >>>>> @@ -4546,6 +4547,7 @@ latency_test_ldpc_dec(struct rte_mempool >>>>> *mempool, >>>>> >>>>> for (i = 0, dequeued = 0; dequeued < num_to_process; ++i) { >>>>> uint16_t enq = 0, deq = 0; >>>>> + uint32_t time_out = 0; >>>>> bool first_time = true; >>>>> last_time = 0; >>>>> >>>>> @@ -4597,7 +4599,8 @@ latency_test_ldpc_dec(struct rte_mempool >>>> *mempool, >>>>> last_time = rte_rdtsc_precise() - start_time; >>>>> first_time = false; >>>>> } >>>>> - } while (unlikely(burst_sz != deq)); >>>>> + time_out++; >>>>> + } while ((burst_sz != deq) && (time_out < TIME_OUT_POLL)); >>>>> >>>>> *max_time = RTE_MAX(*max_time, last_time); >>>>> *min_time = RTE_MIN(*min_time, last_time); @@ -4606,7 >>>> +4609,12 @@ >>>>> latency_test_ldpc_dec(struct rte_mempool *mempool, >>>>> if (extDdr) >>>>> retrieve_harq_ddr(dev_id, queue_id, ops_enq, >>>> burst_sz); >>>>> >>>>> - if (test_vector.op_type != RTE_BBDEV_OP_NONE) { >>>>> + if (burst_sz != deq) { >>>>> + struct rte_bbdev_info info; >>>>> + ret = TEST_FAILED; >>>>> + rte_bbdev_info_get(dev_id, &info); >>>> >>>> What is the point of calling rte_bbdev_info_get() here and below? >>>> info is not used afterwards. >>> >>> The reason for calling this function is to check the device status and if there >> is something wrong the PMD would display it to standard output. >> >> What kind of info exactly, I don't see much meaningful logs in >> rte_bbdev_info_get() except printing error if dev_info == NULL. > > rte_bbdev_info_get() calls the device's info_get function that is specified in the PMD. > For example, for ACC100, acc100_dev_info_get() gets called to check the device status. Ok, I looked at this function and it might be more relevant to mention vrb1 than acc100, because acc100 does not support device status: /* Check the status of device */ dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED; Also, this dev_info->device_status field is set by all the drivers but never read (neither by the driver, nor library nor apps). So if this is the only reason rte_bbdev_info_get() is called, that is quite useless. Am I missing someting? Thanks, Maxime > Thanks, > Hernan >> >> Regards, >> Maxime >> >>>> >>>>> + TEST_ASSERT_SUCCESS(ret, "Dequeue timeout!"); >>>>> + } else if (test_vector.op_type != RTE_BBDEV_OP_NONE) { >>>>> ret = validate_ldpc_dec_op(ops_deq, burst_sz, >>>> ref_op, >>>>> vector_mask); >>>>> TEST_ASSERT_SUCCESS(ret, "Validation failed!"); @@ >>>> -4632,6 >>>>> +4640,7 @@ latency_test_enc(struct rte_mempool *mempool, >>>>> >>>>> for (i = 0, dequeued = 0; dequeued < num_to_process; ++i) { >>>>> uint16_t enq = 0, deq = 0; >>>>> + uint32_t time_out = 0; >>>>> bool first_time = true; >>>>> last_time = 0; >>>>> >>>>> @@ -4667,13 +4676,18 @@ latency_test_enc(struct rte_mempool >>>> *mempool, >>>>> last_time += rte_rdtsc_precise() - start_time; >>>>> first_time = false; >>>>> } >>>>> - } while (unlikely(burst_sz != deq)); >>>>> + time_out++; >>>>> + } while ((burst_sz != deq) && (time_out < TIME_OUT_POLL)); >>>>> >>>>> *max_time = RTE_MAX(*max_time, last_time); >>>>> *min_time = RTE_MIN(*min_time, last_time); >>>>> *total_time += last_time; >>>>> - >>>>> - if (test_vector.op_type != RTE_BBDEV_OP_NONE) { >>>>> + if (burst_sz != deq) { >>>>> + struct rte_bbdev_info info; >>>>> + ret = TEST_FAILED; >>>>> + rte_bbdev_info_get(dev_id, &info); >>>> >>>> Same here. >>>> >>>>> + TEST_ASSERT_SUCCESS(ret, "Dequeue timeout!"); >>>>> + } else if (test_vector.op_type != RTE_BBDEV_OP_NONE) { >>>>> ret = validate_enc_op(ops_deq, burst_sz, ref_op); >>>>> TEST_ASSERT_SUCCESS(ret, "Validation failed!"); >>>>> } >>> >