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 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 ; Mon, 6 Sep 2021 10:06:46 +0200 (CEST) Received: by mail-il1-f173.google.com with SMTP id a1so6038745ilj.6 for ; 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> <86ab7cee-0adb-0e44-94f5-1931f1f8082b@huawei.com> <2ec462fd-c483-3af2-b2b6-898dff271c23@huawei.com> In-Reply-To: <2ec462fd-c483-3af2-b2b6-898dff271c23@huawei.com> From: Jerin Jacob Date: Mon, 6 Sep 2021 13:36:19 +0530 Message-ID: To: fengchengwen Cc: Gagandeep Singh , "thomas@monjalon.net" , "ferruh.yigit@intel.com" , "bruce.richardson@intel.com" , "jerinj@marvell.com" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" , "mb@smartsharesystems.com" , Nipun Gupta , Hemant Agrawal , "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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Sep 6, 2021 at 1:22 PM fengchengwen 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 > >> Sent: Saturday, September 4, 2021 7:02 AM > >> To: Gagandeep Singh ; 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 > >> ; Hemant Agrawal ; > >> 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, > >>> > >>> > >>>> + > >>>> +/** > >>>> + * @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. > > > >> > >>> > >>> > >>> > >>> Regards, > >>> Gagan > >>>