On Thu, Feb 16, 2023 at 09:24:38AM +0800, fengchengwen wrote:
> 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.richard...@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.
>
+1. Thanks.
With this patch in place we will also be better able to help drivers
enforce the correct behaviour once we define it.
I'll do v3 keeping this as-is for now.
/Bruce
