[PATCH v2 6/6] test/dmadev: add tests for stopping and restarting dev
fengchengwen
fengchengwen at huawei.com
Thu Feb 16 02:24:38 CET 2023
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 <bruce.richardson at intel.com> ---
>>> 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
>
> .
>
More information about the dev
mailing list