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 6730441CA9; Thu, 16 Feb 2023 02:24:43 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4C0D540EE3; Thu, 16 Feb 2023 02:24:43 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id BB5AC40695 for ; Thu, 16 Feb 2023 02:24:40 +0100 (CET) Received: from dggpeml500024.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4PHHGz6Y1GzRs4G for ; Thu, 16 Feb 2023 09:22:03 +0800 (CST) Received: from [10.67.100.224] (10.67.100.224) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Thu, 16 Feb 2023 09:24:38 +0800 Subject: Re: [PATCH v2 6/6] test/dmadev: add tests for stopping and restarting dev To: Bruce Richardson CC: , Kevin Laatz References: <20230116153714.554470-1-bruce.richardson@intel.com> <20230116173738.562322-1-bruce.richardson@intel.com> <20230116173738.562322-7-bruce.richardson@intel.com> From: fengchengwen Message-ID: Date: Thu, 16 Feb 2023 09:24:38 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.100.224] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected 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 2023/2/15 19:57, Bruce Richardson wrote: > On Wed, Feb 15, 2023 at 09:59:06AM +0800, fengchengwen wrote: >> On 2023/1/17 1:37, Bruce Richardson wrote: >>> Validate device operation when a device is stopped or restarted. >>> >>> The only complication - and gap in the dmadev ABI specification - is >>> what happens to the job ids on restart. Some drivers reset them to 0, >>> while others continue where things left off. Take account of both >>> possibilities in the test case. >>> >>> Signed-off-by: Bruce Richardson --- >>> app/test/test_dmadev.c | 46 ++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 46 insertions(+) >>> >>> diff --git a/app/test/test_dmadev.c b/app/test/test_dmadev.c index >>> de787c14e2..8fb73a41e2 100644 --- a/app/test/test_dmadev.c +++ >>> b/app/test/test_dmadev.c @@ -304,6 +304,48 @@ >>> test_enqueue_copies(int16_t dev_id, uint16_t vchan) || >>> do_multi_copies(dev_id, vchan, 0, 0, 1); } >>> >>> +static int +test_stop_start(int16_t dev_id, uint16_t vchan) +{ + /* >>> device is already started on input, should be (re)started on output */ >>> + + uint16_t id = 0; + enum rte_dma_status_code status = >>> RTE_DMA_STATUS_SUCCESSFUL; + + /* - test stopping a device works >>> ok, + * - then do a start-stop without doing a copy + * >>> - finally restart the device + * checking for errors at each >>> stage, and validating we can still copy at the end. + */ + if >>> (rte_dma_stop(dev_id) < 0) + ERR_RETURN("Error stopping >>> device\n"); + + if (rte_dma_start(dev_id) < 0) + >>> ERR_RETURN("Error restarting device\n"); + if (rte_dma_stop(dev_id) < >>> 0) + ERR_RETURN("Error stopping device after restart (no >>> jobs executed)\n"); + + if (rte_dma_start(dev_id) < 0) + >>> ERR_RETURN("Error restarting device after multiple stop-starts\n"); + + >>> /* before doing a copy, we need to know what the next id will be it >>> should + * either be: + * - the last completed job before start if >>> driver does not reset id on stop + * - or -1 i.e. next job is 0, if >>> driver does reset the job ids on stop + */ + if >>> (rte_dma_completed_status(dev_id, vchan, 1, &id, &status) != 0) + >>> ERR_RETURN("Error with rte_dma_completed_status when no job done\n"); + >>> id += 1; /* id_count is next job id */ + if (id != id_count && id != >>> 0) + ERR_RETURN("Unexpected next id from device after >>> stop-start. Got %u, expected %u or 0\n", + id, >>> id_count); >> >> Hi Bruce, >> >> Suggest add a warn LOG to identify the id was not reset zero. So that >> new driver could detect break ABI specification. >> > Not sure that that is necessary. The actual ABI, nor the doxygen docs, > doesn't specify what happens to the values on doing stop and then start. My > thinking was that it should continue numbering as it would be equivalent to > suspend and resume, but other drivers appear to treat it as a "reset". I > suspect there are advantages and disadvantages to both schemes. Until we > decide on what the correct behaviour should be - or decide to allow both - > I don't think warning is the right thing to do here. In this point, agree to upstream this patch first, and then discuss the correct behavior should be for restart scenario. > > /Bruce > > . >