From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EADC9C4338F for ; Mon, 23 Aug 2021 14:03:52 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 8296460E78 for ; Mon, 23 Aug 2021 14:03:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8296460E78 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DBEFB4014E; Mon, 23 Aug 2021 16:03:51 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id B559F4014D for ; Mon, 23 Aug 2021 16:03:50 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10084"; a="217137534" X-IronPort-AV: E=Sophos;i="5.84,344,1620716400"; d="scan'208";a="217137534" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Aug 2021 07:03:49 -0700 X-IronPort-AV: E=Sophos;i="5.84,344,1620716400"; d="scan'208";a="454815098" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.21.250]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 23 Aug 2021 07:03:45 -0700 Date: Mon, 23 Aug 2021 15:03:42 +0100 From: Bruce Richardson To: Chengwen Feng Cc: thomas@monjalon.net, ferruh.yigit@intel.com, jerinj@marvell.com, jerinjacobk@gmail.com, andrew.rybchenko@oktetlabs.ru, dev@dpdk.org, mb@smartsharesystems.com, nipun.gupta@nxp.com, hemant.agrawal@nxp.com, maxime.coquelin@redhat.com, honnappa.nagarahalli@arm.com, david.marchand@redhat.com, sburla@marvell.com, pkapoor@marvell.com, konstantin.ananyev@intel.com Message-ID: References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1629689494-55091-1-git-send-email-fengchengwen@huawei.com> <1629689494-55091-8-git-send-email-fengchengwen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1629689494-55091-8-git-send-email-fengchengwen@huawei.com> Subject: Re: [dpdk-dev] [PATCH v16 7/9] dma/skeleton: add test cases 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 Mon, Aug 23, 2021 at 11:31:32AM +0800, Chengwen Feng wrote: > Patch introduces dmadev unit testcase for validation against the > skeleton dmadev PMD implementation. > > Test cases are added along with the skeleton driver implementation. > It can be enabled by using vdev argument to any DPDK binary: > > --vdev="dma_skeleton,selftest=1" > > In case 'selftest=1' is not provided, autotest doesn't execute the > test cases but the vdev is still available for application use. > > Signed-off-by: Chengwen Feng > --- Having self-tests was useful for rawdev implementations as each rawdev was (potentially) a completely different device type so no common set of tests could really be written for them. However, for dmadev, we have a common set of functions and APIs, so I think that the tests provided here should be in a general test-case set. We are preparing to upstream a test suite for DMA devices, based off the work we have in progress on our own drivers, and we'll look to include some of the tests from here in that for consistency. Please wait for that set - hopefully appearing the next day or two - before doing additional work on this set, as our set includes quite a comprehensive set of functional tests in it, which would go well with the API tests here. In terms of the skeleton dmadev itself, I'm not fully convinced of its usefulness, but it does allow unit testing of the APIs in the absense of dma device hardware. Whether that utility is worth the maintenance cost, though, I'm not sure. Regards, /Bruce