From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 3BE89A0C4D;
Mon, 6 Sep 2021 10:06:48 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id B398A40E32;
Mon, 6 Sep 2021 10:06:47 +0200 (CEST)
Received: from mail-il1-f173.google.com (mail-il1-f173.google.com
[209.85.166.173])
by mails.dpdk.org (Postfix) with ESMTP id 6647440C35
for <dev@dpdk.org>; Mon, 6 Sep 2021 10:06:46 +0200 (CEST)
Received: by mail-il1-f173.google.com with SMTP id a1so6038745ilj.6
for <dev@dpdk.org>; Mon, 06 Sep 2021 01:06:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=pGvF9TmvM6nT0/qFug/nfw9SDVFMOWWfPbzk6O7/Els=;
b=PlxN31O2v7sgqJohcFY/rdV9/l+SA1Ui1/20cPWeHRYw0dVgV6FNCPzijI+wbk7Kh0
BsZM+7OlR3pWkXmMltBwR2FYdJHgkjwJjOytMk4kFyzfxWdFy+z5ilYpH58qPlLlOF5r
c6ce/zxepOtuQu9R0H2Ej2FwJ7eA3WRfbBPS9Syd+nwgSyvEOSii+uylkNxGDjpXSxz0
VM8MAFhS/fsR2LIS1b69O6W5LGE3PymUU86cSn3+ifguzMUsgrHlN+cfnjH5TFTbqdr0
rD4eDj6nOra0VpQz6/nUuCE5p3mKaVY6gEzy4Fkfpd+9K7dqo5SnNuoUGfR5PoH3Eb5U
+YVw==
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;
bh=pGvF9TmvM6nT0/qFug/nfw9SDVFMOWWfPbzk6O7/Els=;
b=HhgpRyRWixlOoxIAUYOHUXPG5LtNlNKEOtQDcpo4gfJApHnr1HARj6IMeqABGrrO2M
TyCeZQpD0s3fk+ncW6pXoTfof5BM47KDNosXKUVrL38qgS1UTDYVQSr5cMtbHfuIYbM5
djOhfGcVkcoAyZ1L01cnSsryy1LEHF3PMVJ3Tm5iRM83IypX+Fr/WEDocwky5t0/4IT0
HBs7h4rKZIzl3Y+ITd6+6R0ezWMyPvvzA3GTj8Q1Oxzk4tOV/lY/re5v6g4O16apiKZ4
y9DnswChNp90634O2jCfgQyTknrWVRBvm1U+4pf8B4fkEQYpF7EUtmQImAVVWxyDWGa7
fmiw==
X-Gm-Message-State: AOAM532LMqGxnd2jQBwf+ET3FK6IDF7qLvlmLbAYNdW+SZffcStJ/ieF
H0mdjmNAkiwDJ80YHYeJx5rJONJLEBwkrAVz2l0=
X-Google-Smtp-Source: ABdhPJz3R0tN3bz1QjCqLYGV4ffbHEY6qiuF4w27G+t0LnwO/aN5j33iMFYtlMyZoPiO/jzdWCOZiWJweHmBvFSpXuc=
X-Received: by 2002:a92:4b02:: with SMTP id m2mr7020573ilg.94.1630915605615;
Mon, 06 Sep 2021 01:06:45 -0700 (PDT)
MIME-Version: 1.0
References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com>
<1630588395-2804-1-git-send-email-fengchengwen@huawei.com>
<1630588395-2804-2-git-send-email-fengchengwen@huawei.com>
<VI1PR04MB696044A51BDE23DF7B0C3CDBE1CF9@VI1PR04MB6960.eurprd04.prod.outlook.com>
<86ab7cee-0adb-0e44-94f5-1931f1f8082b@huawei.com>
<VI1PR04MB696004326C94667A4F2C7E26E1D29@VI1PR04MB6960.eurprd04.prod.outlook.com>
<2ec462fd-c483-3af2-b2b6-898dff271c23@huawei.com>
In-Reply-To: <2ec462fd-c483-3af2-b2b6-898dff271c23@huawei.com>
From: Jerin Jacob <jerinjacobk@gmail.com>
Date: Mon, 6 Sep 2021 13:36:19 +0530
Message-ID: <CALBAE1OMDK_8pCrBcpKJTfyPbq8ccNRHbdVJtr46zA3zAv8nbQ@mail.gmail.com>
To: fengchengwen <fengchengwen@huawei.com>
Cc: Gagandeep Singh <G.Singh@nxp.com>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"jerinj@marvell.com" <jerinj@marvell.com>,
"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
"dev@dpdk.org" <dev@dpdk.org>,
"mb@smartsharesystems.com" <mb@smartsharesystems.com>,
Nipun Gupta <nipun.gupta@nxp.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
"honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>,
"david.marchand@redhat.com" <david.marchand@redhat.com>,
"sburla@marvell.com" <sburla@marvell.com>,
"pkapoor@marvell.com" <pkapoor@marvell.com>,
"konstantin.ananyev@intel.com" <konstantin.ananyev@intel.com>,
"conor.walsh@intel.com" <conor.walsh@intel.com>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [dpdk-dev] [PATCH v19 1/7] dmadev: introduce DMA device library
public APIs
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On Mon, Sep 6, 2021 at 1:22 PM fengchengwen <fengchengwen@huawei.com> wrote:
>
> I think we can add support for DIR_ANY.
> @Bruce @Jerin Would you please take a look at my proposal?
Since the channel is virtual, it will be cheap to avoid any fast path
flags and keep the current scheme
as it max we will have 4 channels for directions.
No strong opinion, if other things, that is the better way, I think,
it is okay too.
>
> On 2021/9/6 14:48, Gagandeep Singh wrote:
> >
> >
> >> -----Original Message-----
> >> From: fengchengwen <fengchengwen@huawei.com>
> >> Sent: Saturday, September 4, 2021 7:02 AM
> >> To: Gagandeep Singh <G.Singh@nxp.com>; thomas@monjalon.net;
> >> ferruh.yigit@intel.com; bruce.richardson@intel.com; jerinj@marvell.com;
> >> jerinjacobk@gmail.com; andrew.rybchenko@oktetlabs.ru
> >> Cc: dev@dpdk.org; mb@smartsharesystems.com; Nipun Gupta
> >> <nipun.gupta@nxp.com>; Hemant Agrawal <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; conor.walsh@intel.com
> >> Subject: Re: [dpdk-dev] [PATCH v19 1/7] dmadev: introduce DMA device library
> >> public APIs
> >>
> >> On 2021/9/3 19:42, Gagandeep Singh wrote:
> >>> Hi,
> >>>
> >>> <snip>
> >>>> +
> >>>> +/**
> >>>> + * @warning
> >>>> + * @b EXPERIMENTAL: this API may change without prior notice.
> >>>> + *
> >>>> + * Close a DMA device.
> >>>> + *
> >>>> + * The device cannot be restarted after this call.
> >>>> + *
> >>>> + * @param dev_id
> >>>> + * The identifier of the device.
> >>>> + *
> >>>> + * @return
> >>>> + * 0 on success. Otherwise negative value is returned.
> >>>> + */
> >>>> +__rte_experimental
> >>>> +int
> >>>> +rte_dmadev_close(uint16_t dev_id);
> >>>> +
> >>>> +/**
> >>>> + * rte_dma_direction - DMA transfer direction defines.
> >>>> + */
> >>>> +enum rte_dma_direction {
> >>>> + RTE_DMA_DIR_MEM_TO_MEM,
> >>>> + /**< DMA transfer direction - from memory to memory.
> >>>> + *
> >>>> + * @see struct rte_dmadev_vchan_conf::direction
> >>>> + */
> >>>> + RTE_DMA_DIR_MEM_TO_DEV,
> >>>> + /**< DMA transfer direction - from memory to device.
> >>>> + * In a typical scenario, the SoCs are installed on host servers as
> >>>> + * iNICs through the PCIe interface. In this case, the SoCs works in
> >>>> + * EP(endpoint) mode, it could initiate a DMA move request from
> >>>> memory
> >>>> + * (which is SoCs memory) to device (which is host memory).
> >>>> + *
> >>>> + * @see struct rte_dmadev_vchan_conf::direction
> >>>> + */
> >>>> + RTE_DMA_DIR_DEV_TO_MEM,
> >>>> + /**< DMA transfer direction - from device to memory.
> >>>> + * In a typical scenario, the SoCs are installed on host servers as
> >>>> + * iNICs through the PCIe interface. In this case, the SoCs works in
> >>>> + * EP(endpoint) mode, it could initiate a DMA move request from device
> >>>> + * (which is host memory) to memory (which is SoCs memory).
> >>>> + *
> >>>> + * @see struct rte_dmadev_vchan_conf::direction
> >>>> + */
> >>>> + RTE_DMA_DIR_DEV_TO_DEV,
> >>>> + /**< DMA transfer direction - from device to device.
> >>>> + * In a typical scenario, the SoCs are installed on host servers as
> >>>> + * iNICs through the PCIe interface. In this case, the SoCs works in
> >>>> + * EP(endpoint) mode, it could initiate a DMA move request from device
> >>>> + * (which is host memory) to the device (which is another host memory).
> >>>> + *
> >>>> + * @see struct rte_dmadev_vchan_conf::direction
> >>>> + */
> >>>> +};
> >>>> +
> >>>> +/**
> >>>> ..
> >>> The enum rte_dma_direction must have a member RTE_DMA_DIR_ANY for a
> >> channel that supports all 4 directions.
> >>
> >> We've discussed this issue before. The earliest solution was to set up channels to
> >> support multiple DIRs, but
> >> no hardware/driver actually used this (at least at that time). they (like
> >> octeontx2_dma/dpaa) all setup one logic
> >> channel server single transfer direction.
> >>
> >> So, do you have that kind of desire for your driver ?
> >>
> > Both DPAA1 and DPAA2 drivers can support ANY direction on a channel, so we would like to have this option as well.
> >
> >>
> >> If you have a strong desire, we'll consider the following options:
> >>
> >> Once the channel was setup, there are no other parameters to indicate the copy
> >> request's transfer direction.
> >> So I think it is not enough to define RTE_DMA_DIR_ANY only.
> >>
> >> Maybe we could add RTE_DMA_OP_xxx marco
> >> (RTE_DMA_OP_FLAG_M2M/M2D/D2M/D2D), these macro will as the flags
> >> parameter
> >> passsed to enqueue API, so the enqueue API knows which transfer direction the
> >> request corresponding.
> >>
> >> We can easily expand from the existing framework with following:
> >> a. define capability RTE_DMADEV_CAPA_DIR_ANY, for those device which
> >> support it could declare it.
> >> b. define direction macro: RTE_DMA_DIR_ANY
> >> c. define dma_op: RTE_DMA_OP_FLAG_DIR_M2M/M2D/D2M/D2D which will
> >> passed as the flags parameters.
> >>
> >> For that driver which don't support this feature, just don't declare support it, and
> >> framework ensure that
> >> RTE_DMA_DIR_ANY is not passed down, and it can ignored
> >> RTE_DMA_OP_FLAG_DIR_xxx flag when enqueue API.
> >>
> >> For that driver which support this feature, application could create one channel
> >> with RTE_DMA_DIR_ANY or RTE_DMA_DIR_MEM_TO_MEM.
> >> If created with RTE_DMA_DIR_ANY, the RTE_DMA_OP_FLAG_DIR_xxx should be
> >> sensed in the driver.
> >> If created with RTE_DMA_DIR_MEM_TO_MEM, the
> >> RTE_DMA_OP_FLAG_DIR_xxx could be ignored.
> >>
> > Your design looks ok to me.
> >
> >>
> >>> <snip>
> >>>
> >>>
> >>> Regards,
> >>> Gagan
> >>>