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 CD5C3A0A0C; Sat, 3 Jul 2021 11:09:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5A65D40C35; Sat, 3 Jul 2021 11:09:23 +0200 (CEST) Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) by mails.dpdk.org (Postfix) with ESMTP id B6F3440696 for ; Sat, 3 Jul 2021 11:09:22 +0200 (CEST) Received: by mail-il1-f180.google.com with SMTP id f12so5750641ils.11 for ; Sat, 03 Jul 2021 02:09:22 -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=VhHiP/G7eX9Tve8kRZjj0H0rYTgoizuKqR7SgdXlVHY=; b=q3cyE1BbXXnYi8yaInlcjisLae6lD8XXwjX3j7KC4CGO/gbBkMACUIriMsqvlJ6jii ARWMPvdrDuQmTLQkeBTzdDyJFe0sVw96WwDtWwGOOLZpWmv6O9hbG2RPSJaXbXkNfCLk mB+YBjSkOUl2bB1qiMlbbzduZryxchREtEOQEaPo5BBIFD4YFaCpwVNNjgF1o1sPImO0 jmmWfdI5mVtClOZ7Bhjedd1K0I4zALnhiNnbeVvj2hP4jzr7KbR6wCD1A6Gb4NeCKIoU Fz1puX9vex0ZncHlrAs6aGHWxZ6qM8Ov0SpdKAYmtrgcnPZhNUp7CHbA7oudP4t7XQnD E9/w== 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=VhHiP/G7eX9Tve8kRZjj0H0rYTgoizuKqR7SgdXlVHY=; b=jZAjyGzKULs4c7SzDmRkhK7ukGmKaxjdCMuZvnsE1+zqChG39Ye0qOKkhUBYv4gVqk fW61b+3rwZvrcx0KdxINf5fXXoZLqe0geugb02BAEy40K504eqO6LUdKP10keoYNbaYL naxJ3qtf7/AAL+VeVmM9yXao9mi7Qu1dOtn6TBi6BYP3HWErPtxelgzN2Oux/ZF5ihnt YBEFNeCrk9Ba8mNvFrsyydU6/SVGggHN3GawhXP7Sat6GeLnF7+8PfUqwJudbSgr1eqI KjEFROy7ukKfMaHPGlL/+LrGzZrQuMigbSTujOOuRQpSyuKk89NcKcD6fMltFM6TMP/r wVNA== X-Gm-Message-State: AOAM532eT0q/ibRSlM9MYtXufmMYaXfdbQaR8utGDzumsRldOy3d3+vb qSIJ9gkXgDoSNgPUNSooZ5aTbEdFcvNYsDnbKGA= X-Google-Smtp-Source: ABdhPJyxK1zetUE6KmCGa7c3UAMCaKSfjsNo5/tiWirTTeYDNi9JMp05EGKiUnxvAFFPLj3Tc1GPi6QVcRqAqotZY4Y= X-Received: by 2002:a05:6e02:1a04:: with SMTP id s4mr2813832ild.294.1625303361888; Sat, 03 Jul 2021 02:09:21 -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> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C618DC@smartserver.smartshare.dk> From: Jerin Jacob Date: Sat, 3 Jul 2021 14:38:55 +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 2:23 PM 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 impo= rtant high level detail still not decided: > > Bruce had suggested flattening the DMA channels, so each dmadev represent= s a DMA channel. And DMA controllers with multiple DMA channels will have t= o instantiate multiple dmadevs, one for each DMA channel. > > 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. > > However, this assumes that the fast path functions on the individual DMA = channels of a DMA controller can be accessed completely independently and s= imultaneously by multiple threads. (Otherwise, the driver would need to imp= lement critical regions or locking around accessing the common registers in= the DMA controller shared by the DMA channels.) > > Unless any of the DMA controller vendors claim that this assumption about= independence of the DMA channels is wrong, I strongly support Bruce's flat= tening suggestion. It is wrong from alteast octeontx2_dma PoV. # The PCI device is DMA controller where the driver/device is mapped.(As device driver is based on PCI bus, We dont want to have vdev for this) # The PCI device has HW queue(s) # Each HW queue has different channels. In the current configuration, we have only one queue per device and it has 4 channels. 4 channels are not threaded safe as it is based on single queue. I think, if we need to flatten it, I think, it makes sense to have dmadev <> channel (and each channel can have thread-safe capability based on how it mapped on HW queues based on the device driver capability). > > -Morten >