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 18DE7A0C43; Wed, 20 Oct 2021 11:52:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 07A8F40687; Wed, 20 Oct 2021 11:52:57 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id B7A5140142 for ; Wed, 20 Oct 2021 11:52:54 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10142"; a="227511452" X-IronPort-AV: E=Sophos;i="5.87,166,1631602800"; d="scan'208";a="227511452" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2021 02:52:53 -0700 X-IronPort-AV: E=Sophos;i="5.87,166,1631602800"; d="scan'208";a="494549809" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.29.221]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 20 Oct 2021 02:52:51 -0700 Date: Wed, 20 Oct 2021 10:52:48 +0100 From: Bruce Richardson To: fengchengwen Cc: Kevin Laatz , dev@dpdk.org, thomas@monjalon.net, jerinj@marvell.com, conor.walsh@intel.com Message-ID: References: <20210827172048.558704-1-kevin.laatz@intel.com> <20211019141041.1890983-1-kevin.laatz@intel.com> <20211019141041.1890983-13-kevin.laatz@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v10 12/16] dma/idxd: add vchan status function 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 Sender: "dev" On Wed, Oct 20, 2021 at 05:30:13PM +0800, fengchengwen wrote: > On 2021/10/19 22:10, Kevin Laatz wrote: > > When testing dmadev drivers, it is useful to have the HW device in a known > > state. This patch adds the implementation of the function which will wait > > for the device to be idle (all jobs completed) before proceeding. > > > > Signed-off-by: Kevin Laatz > > Reviewed-by: Conor Walsh > > --- > > drivers/dma/idxd/idxd_bus.c | 1 + > > drivers/dma/idxd/idxd_common.c | 17 +++++++++++++++++ > > drivers/dma/idxd/idxd_internal.h | 2 ++ > > drivers/dma/idxd/idxd_pci.c | 1 + > > 4 files changed, 21 insertions(+) > > > > diff --git a/drivers/dma/idxd/idxd_bus.c b/drivers/dma/idxd/idxd_bus.c > > index b52ea02854..e6caa048a9 100644 > > --- a/drivers/dma/idxd/idxd_bus.c > > +++ b/drivers/dma/idxd/idxd_bus.c > > @@ -101,6 +101,7 @@ static const struct rte_dma_dev_ops idxd_bus_ops = { > > .dev_info_get = idxd_info_get, > > .stats_get = idxd_stats_get, > > .stats_reset = idxd_stats_reset, > > + .vchan_status = idxd_vchan_status, > > }; > > > > static void * > > diff --git a/drivers/dma/idxd/idxd_common.c b/drivers/dma/idxd/idxd_common.c > > index fd81418b7c..3c8cff15c0 100644 > > --- a/drivers/dma/idxd/idxd_common.c > > +++ b/drivers/dma/idxd/idxd_common.c > > @@ -163,6 +163,23 @@ get_comp_status(struct idxd_completion *c) > > } > > } > > > > +int > > +idxd_vchan_status(const struct rte_dma_dev *dev, uint16_t vchan __rte_unused, > > + enum rte_dma_vchan_status *status) > > +{ > > + struct idxd_dmadev *idxd = dev->fp_obj->dev_private; > > + uint16_t last_batch_write = idxd->batch_idx_write == 0 ? idxd->max_batches : > > + idxd->batch_idx_write - 1; > > + uint8_t bstatus = (idxd->batch_comp_ring[last_batch_write].status != 0); > > + > > + /* An IDXD device will always be either active or idle. > > + * RTE_DMA_VCHAN_HALTED_ERROR is therefore not supported by IDXD. > > + */ > > + *status = bstatus ? RTE_DMA_VCHAN_IDLE : RTE_DMA_VCHAN_ACTIVE; > > why not use stats.submitted and completed ? or I miss some thing about this API? > > does this api must called after rte_dma_submit() ? If not the following seq will function fail: > enqueue multiple copy request > submit to hardware > enqueue multiple copy request > invoke rte_dma_vchan_status to query status --because the copy requests not submit, the last comp will be non-zero, so it will return IDLE. > That is correct. Until the jobs are submitted the device HW is idle as it is not processing any job. This API is to return the HW state, because that is the key concern here, whether the HW is in the process of doing DMA or not, since that is what can cause race conditions. The timing of sending down jobs to the device is under app control.