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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 53023C07E95 for ; Sun, 4 Jul 2021 07:34:34 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id C75D66115C for ; Sun, 4 Jul 2021 07:34:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C75D66115C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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 979DC40040; Sun, 4 Jul 2021 09:34:32 +0200 (CEST) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by mails.dpdk.org (Postfix) with ESMTP id EDADA4003F for ; Sun, 4 Jul 2021 09:34:31 +0200 (CEST) Received: by mail-il1-f181.google.com with SMTP id b5so14134493ilc.12 for ; Sun, 04 Jul 2021 00:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Pz/QF8E5hBAioDx2asTFkAdTN9LiMUbLl46WLBCVhRQ=; b=bPO7EWyNTmaLiBwzY27EyTm/ARHzRLYGRVH0NIYs2Cla7b3TTZXCOld/XR3be4dAmj 9QERS8A7SKPiASwiVhfFsWLI31+vU+o8JbqG/qOoM8WJFOe/JgJmorFGl0UETUrtJ6Tn /tAdUl9mPFAR9AeAfA26u8aWq6nN04fWeM1u2TFBOBeY8h9o/Kb0FBdNMZVcXDiL4qfC VX+YRm9pCnOh4x71oNiF7yyXpPv/xHJyDMxQuvrl/Mrw3hC7mLgnkt/uPZLrZ2SVilGm eNk7sb7R7lOdCclazBcAFdR/zg6sZWxuEQSiivGtUsx5DQFA5D8mSohhfJ+F2fTA8AzW bZ9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Pz/QF8E5hBAioDx2asTFkAdTN9LiMUbLl46WLBCVhRQ=; b=f9cmRsMu3ihRS+71q6HtJ2k4CGOQvnibsNhzEIGRQiVC2/JPXcuCofQZpvlVMwHuBB nwNFr9QlXodAFatFT/Qzc9e8Omd1Lk0uJXl0jxqOq13fx2B0N42wcP24HJ3TCW4CvxQe 4gDLQfjLHKISfpkmVs9/u6o8lxuRPk13tZLUvlo6AB9N0m0vj69EVglMz+KF4ShVjzR1 cftzF1fAHrgVXFQpNLSH4WaU75NsFTG7VsI81J4t7XbyNr492FSGTWfh4JY7prIXY/Gv X8Tjlp107Wa28xmkGVJA1uhdBh9rzNFQ985EIzOmARcK4KmJ6JUzF3Dt6tcMXXKPeRbl V3fQ== X-Gm-Message-State: AOAM532bD/xuuGPd/muJQB1cHfiyGt/NBiZ5EPNomKvunpkNQMdylN6Y +v6tkWAG41w9X3jF7og6LmUXt/p6slYCbHk4G6U= X-Google-Smtp-Source: ABdhPJyUGAOfcIg6f5vYXFFRMEmMQ20gz1jJ635DPZEq+ZHP+b4DUUZkFPwP2kK4A9HEywXfagguCfLk94Es7x2e9ZE= X-Received: by 2002:a92:bf0b:: with SMTP id z11mr6271490ilh.60.1625384071205; Sun, 04 Jul 2021 00:34:31 -0700 (PDT) MIME-Version: 1.0 References: <1623763327-30987-1-git-send-email-fengchengwen@huawei.com> <25d29598-c26d-8497-2867-9b650c79df49@huawei.com> <3db2eda0-4490-2b8f-c65d-636bcf794494@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35C618D9@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C618DC@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C618DE@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C618DE@smartserver.smartshare.dk> From: Jerin Jacob Date: Sun, 4 Jul 2021 13:04:05 +0530 Message-ID: To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: fengchengwen , Bruce Richardson , Jerin Jacob , Nipun Gupta , Thomas Monjalon , Ferruh Yigit , dpdk-dev , Hemant Agrawal , Maxime Coquelin , Honnappa Nagarahalli , David Marchand , Satananda Burla , Prasun Kapoor Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] dmadev discussion summary 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 Sat, Jul 3, 2021 at 5:30 PM Morten Br=C3=B8rup wrote: > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of fengchengwen > > Sent: Saturday, 3 July 2021 11.45 > > > > On 2021/7/3 16:53, Morten Br=C3=B8rup wrote: > > >> From: fengchengwen [mailto:fengchengwen@huawei.com] > > >> Sent: Saturday, 3 July 2021 02.32 > > >> > > >> On 2021/7/2 22:57, Morten Br=C3=B8rup wrote: > > >>>> In the DPDK framework, many data-plane API names contain queues. > > >> e.g. > > >>>> eventdev/crypto.. > > >>>> The concept of virt queues has continuity. > > >>> > > >>> I was also wondering about the name "virtual queue". > > >>> > > >>> Usually, something "virtual" would be an abstraction of something > > >> physical, e.g. a software layer on top of something physical. > > >>> > > >>> Back in the days, a "DMA channel" used to mean a DMA engine on a > > CPU. > > >> If a CPU had 2 DMA channels, they could both be set up > > simultaneously. > > >>> > > >>> The current design has the "dmadev" representing a CPU or other > > chip, > > >> which has one or more "HW-queues" representing DMA channels (of the > > >> same type), and then "virt-queue" as a software abstraction on top, > > for > > >> using a DMA channel in different ways through individually > > configured > > >> contexts (virt-queues). > > >>> > > >>> It makes sense to me, although I would consider renaming "HW-queue" > > >> to "channel" and perhaps "virt-queue" to "queue". > > >> > > >> The 'DMA channel' is more used than 'DMA queue', at least google > > show > > >> that there are at least 20+ times more. > > >> > > >> It's a good idea build the abstraction layer: queue <> channel <> > > dma- > > >> controller. > > >> In this way, the meaning of each layer is relatively easy to > > >> distinguish literally. > > >> > > >> will fix in V2 > > >> > > > > > > After re-reading all the mails in this thread, I have found one more > > important high level detail still not decided: > > > > > > Bruce had suggested flattening the DMA channels, so each dmadev > > represents a DMA channel. And DMA controllers with multiple DMA > > channels will have to instantiate multiple dmadevs, one for each DMA > > channel. > > > > The dpaa2_qdma support multiple DMA channels, I looked into the > > dpaa2_qdma > > and found the control-plane interacts with the kernel, so if we use the > > flattening model, there maybe interactions between dmadevs. > > It is perfectly acceptable for the control-plane DMA controller functions= to interact across multiple dmadevs, not being thread safe and using locks= etc. to protect critical regions accessing shared registers. > > The key question is: Can the data-plane dmadev functions (rte_dma_copy() = etc.) be implemented to be thread safe, so multiple threads can use data-pl= ane dmadev functions simultaneously? It can . if we need it in that way. > > > > > > > > > Just like a four port NIC instantiates four ethdevs. > > > > > > Then, like ethdevs, there would only be two abstraction layers: > > dmadev <> queue, where a dmadev is a DMA channel on a DMA controller. > > > > the dmadev <> channel <> queue model, there are three abstraction > > layers, > > and two abstraction layers. > > > > > > > > However, this assumes that the fast path functions on the individual > > DMA channels of a DMA controller can be accessed completely > > independently and simultaneously by multiple threads. (Otherwise, the > > driver would need to implement critical regions or locking around > > accessing the common registers in the DMA controller shared by the DMA > > channels.) > > > > Yes, this scheme has a big implicit dependency, that is, the channels > > are > > independent of each other. > > > > > > > > Unless any of the DMA controller vendors claim that this assumption > > about independence of the DMA channels is wrong, I strongly support > > Bruce's flattening suggestion. > > > > > > -Morten > > > > > >