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 5A5F6A0C4C; Thu, 2 Sep 2021 16:21:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EE8524003E; Thu, 2 Sep 2021 16:21:34 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 962B94003C for ; Thu, 2 Sep 2021 16:21:33 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10094"; a="206348412" X-IronPort-AV: E=Sophos;i="5.85,372,1624345200"; d="scan'208";a="206348412" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2021 07:21:22 -0700 X-IronPort-AV: E=Sophos;i="5.85,372,1624345200"; d="scan'208";a="542752711" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.1.171]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 02 Sep 2021 07:21:18 -0700 Date: Thu, 2 Sep 2021 15:21:15 +0100 From: Bruce Richardson To: fengchengwen Cc: dev@dpdk.org, conor.walsh@intel.com, kevin.laatz@intel.com, jerinj@marvell.com Message-ID: References: <20210826183301.333442-1-bruce.richardson@intel.com> <20210901163216.120087-1-bruce.richardson@intel.com> <20210901163216.120087-2-bruce.richardson@intel.com> <9e6f7f55-3716-9cbe-5c68-97d547b4b069@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e6f7f55-3716-9cbe-5c68-97d547b4b069@huawei.com> Subject: Re: [dpdk-dev] [PATCH v2 1/6] dmadev: add device idle check for testing use 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 Thu, Sep 02, 2021 at 08:54:11PM +0800, fengchengwen wrote: > When some hardware is faulty, the error code cannot be set, and it just stops working. > In addition, interrupts are generally not enabled. Therefore, for such hardware, the > framework needs to have a mechanism to transmit the status so that applications can > sense the status. > > So how about extend vchan_idle to vchan_status, include: idle, running, error-stop ? > We can look at changing that. By "idle" I originally meant "non-active", meaning that it's either halted or idle, but I think we can separate out those two into separate items like you suggest. /Bruce