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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 04FCCC07E96 for ; Tue, 6 Jul 2021 09:08:18 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 84D0561995 for ; Tue, 6 Jul 2021 09:08:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 84D0561995 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 892A140688; Tue, 6 Jul 2021 11:08:15 +0200 (CEST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id 191F34067E for ; Tue, 6 Jul 2021 11:08:13 +0200 (CEST) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4GJxS569S4z762y; Tue, 6 Jul 2021 17:03:49 +0800 (CST) Received: from dggpeml500024.china.huawei.com (7.185.36.10) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 6 Jul 2021 17:08:09 +0800 Received: from [127.0.0.1] (10.40.190.165) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 6 Jul 2021 17:08:09 +0800 To: Matan Azrad , NBU-Contact-Thomas Monjalon , "ferruh.yigit@intel.com" , "bruce.richardson@intel.com" , "jerinj@marvell.com" , "jerinjacobk@gmail.com" CC: "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" , "liangma@liangbit.com" References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <698de550-da08-1319-bb86-60ffa71f0cc3@huawei.com> From: fengchengwen Message-ID: <89935fd4-4558-23fd-e0bd-4db2d5840bf6@huawei.com> Date: Tue, 6 Jul 2021 17:08:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.40.190.165] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [PATCH] dmadev: introduce DMA device library 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 2021/7/6 14:50, Matan Azrad wrote: > Hi > > From: fengchengwen >> On 2021/7/4 23:21, Matan Azrad wrote: >>> >>> >>> From: Chengwen Feng >>>> This patch introduces 'dmadevice' which is a generic type of DMA >>>> device. >>>> >>>> The APIs of dmadev library exposes some generic operations which can >>>> enable configuration and I/O with the DMA devices. >>>> >>> Did you consider RTE_COMP_ALGO_NULL xform in compressdev library? >>> >> >> em, I just looked at the code. >> >> The RTE_COMP_ALGO_NULL is a small feature of the compression device. >> and currently only mlx5 and isal support it. > > Yes, but what that is mean? > If more drivers support DMA operations they can add the support there, no? > You mean to expand directly on compressdev ? I think it hard to expand, and may break the compressdev concept. > >> Also the compressdev dataplane API relatively complicated to do just DMA >> copy. > > You snipped more comments I wrote below 😊 > Maybe it is related.... Sorry, I just skipped. 'Did you consider also mbuf API usage for memory descriptor?' ---One scenario of the DMA is vhost-net, which src or dst could be mbuf, but the peer were not mbuf. so here we use raw fields. > >> So I think we need a separate driver framework for the DMA device. > > Need to consider deprecation in compressdev if so.... > >> thanks >> >> [snip] >> >>> >>> >>> . >>> >