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 E928DA0C48; Mon, 12 Jul 2021 11:59:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 680D64069D; Mon, 12 Jul 2021 11:59:56 +0200 (CEST) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) by mails.dpdk.org (Postfix) with ESMTP id 3645540685 for ; Mon, 12 Jul 2021 11:59:55 +0200 (CEST) Received: by mail-il1-f176.google.com with SMTP id m3so12159057ilj.8 for ; Mon, 12 Jul 2021 02:59:55 -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; bh=HyGlBQhY0pfxQl6MGFYk1rMpMbl0NvE003Y18X9Iz3w=; b=AgRuXAujJWDog1qX7hu+bZrqfDYdNP/XLcTHnmy8hrlYHiWCn0E+C7u5P/yASHgOlC +FcIjeAC0a3N5AGyKdZbP8zj26TUkyw+8Dqe7tzi58wHsuBv2TPxnzanRojDnUtMDFpk 3n7NRjBmmjHjPUeW033CxAUO71AyAz5sOLR9hi7+lV09+IzVw1+GhGvqHhNLDqSc1uet UWjHNAnA4jIYn+WKU8b4+Wifj1rFSnM8SyTngpnDAMuoJ+vCgWA9LOn1kNTVF+6/kYsw kXXee2NIqfYiTzh21GPkP6gMEhzPpjJ9xhdK8LlmlVkAv8b+jG4+w7juzSqFys2ElLqw l18w== 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=HyGlBQhY0pfxQl6MGFYk1rMpMbl0NvE003Y18X9Iz3w=; b=aeVZoikZXtaASJGyWD7UAijawHpMQD+xR9ZsrBVOy4jBjZ9bmGBavC0FFeGPAuQxRc 2ID6pVHX+x+09Wz12sN7Un9oIxk8demvPfBtRff+btEs7kwdrfeLSwQGJ/39nJqt92ea d6wXgTJWgAWIjwr0myzhKD+Fgmgmn2fbMu5UayjTZEgryN3nKXFxANvkE1dTsloRATEM jIkEFg5FNpGjVMazJRVMsZ4k4MJ4EeI/L25V7QihHsVxhH8wgGY/VoxpshRWmm4LdjES 3U2TEitnkqNstkPaThA7+IYWhkI6UzAtoTIr7vNEPacUjGPzCWZh9bipW8iO/AIB2zJ7 pbMw== X-Gm-Message-State: AOAM531flmL6rRpXYT/5eplq5ENlvExZuLuClmqKGBfNTFYEPUNLTZmt 5kyUzS4HJhKJOH7tzJkNF0Y1yx4b+bTyek/KNTg= X-Google-Smtp-Source: ABdhPJzjkc1ZXv27DssQfl+FoKGqeE2n+GSlqz0fCWShZkBLwpi8QrelKoORP1ok2ec+nXiSMWBQ8I0PYp5bgPi12XE= X-Received: by 2002:a92:bf0b:: with SMTP id z11mr38832408ilh.60.1626083994405; Mon, 12 Jul 2021 02:59:54 -0700 (PDT) MIME-Version: 1.0 References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1625995556-41473-1-git-send-email-fengchengwen@huawei.com> In-Reply-To: <1625995556-41473-1-git-send-email-fengchengwen@huawei.com> From: Jerin Jacob Date: Mon, 12 Jul 2021 15:29:27 +0530 Message-ID: To: Chengwen Feng Cc: Thomas Monjalon , Ferruh Yigit , "Richardson, Bruce" , Jerin Jacob , dpdk-dev , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Nipun Gupta , Hemant Agrawal , Maxime Coquelin , Honnappa Nagarahalli , David Marchand , Satananda Burla , Prasun Kapoor , "Ananyev, Konstantin" , liangma@liangbit.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2] 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 Sun, Jul 11, 2021 at 2:59 PM Chengwen Feng wrote: > > This patch introduce '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. > > Signed-off-by: Chengwen Feng > --- > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice. > + * > + * Enqueue a fill operation onto the virtual DMA channel. > + * > + * This queues up a fill operation to be performed by hardware, but does not > + * trigger hardware to begin that operation. > + * > + * @param dev_id > + * The identifier of the device. > + * @param vchan > + * The identifier of virtual DMA channel. > + * @param pattern > + * The pattern to populate the destination buffer with. > + * @param dst > + * The address of the destination buffer. > + * @param length > + * The length of the destination buffer. > + * @param flags > + * An flags for this operation. > + * > + * @return > + * - 0..UINT16_MAX: index of enqueued copy job. fill job > + * - <0: Error code returned by the driver copy function. > + */ > +__rte_experimental > +static inline int > +rte_dmadev_fill(uint16_t dev_id, uint16_t vchan, uint64_t pattern, > + rte_iova_t dst, uint32_t length, uint64_t flags) > +{ > + struct rte_dmadev *dev = &rte_dmadevices[dev_id]; > +#ifdef RTE_DMADEV_DEBUG > + RTE_DMADEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL); > + RTE_FUNC_PTR_OR_ERR_RET(*dev->fill, -ENOTSUP); > + if (vchan >= dev->data->dev_conf.max_vchans) { > + RTE_DMADEV_LOG(ERR, "Invalid vchan %d\n", vchan); > + return -EINVAL; > + } > +#endif > + return (*dev->fill)(dev, vchan, pattern, dst, length, flags); > +} > + > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice. > + * > + * Returns the number of operations that have been successfully completed. > + * > + * @param dev_id > + * The identifier of the device. > + * @param vchan > + * The identifier of virtual DMA channel. > + * @param nb_cpls > + * The maximum number of completed operations that can be processed. > + * @param[out] last_idx > + * The last completed operation's index. > + * If not required, NULL can be passed in. This means the driver will be tracking the last index. Is that mean, the application needs to call this API periodically to consume the completion slot. I.e up to 64K (UINT16_MAX) outstanding jobs are possible. If the application fails to call this >64K outstand job then the subsequence enqueue will fail. If so, we need to document this. One of the concerns of keeping UINT16_MAX as the limit is the completion memory will always not in cache. On the other hand, if we make this size programmable. it may introduce complexity in the application. Thoughts? > + * @param[out] has_error > + * Indicates if there are transfer error. > + * If not required, NULL can be passed in. > + * > + * @return > + * The number of operations that successfully completed. > + */ > +__rte_experimental > +static inline uint16_t > +rte_dmadev_completed(uint16_t dev_id, uint16_t vchan, const uint16_t nb_cpls, > + uint16_t *last_idx, bool *has_error) > +{ > + struct rte_dmadev *dev = &rte_dmadevices[dev_id]; > + uint16_t idx; > + bool err; > + > +#ifdef RTE_DMADEV_DEBUG > + RTE_DMADEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL); > + RTE_FUNC_PTR_OR_ERR_RET(*dev->completed, -ENOTSUP); > + if (vchan >= dev->data->dev_conf.max_vchans) { > + RTE_DMADEV_LOG(ERR, "Invalid vchan %d\n", vchan); > + return -EINVAL; > + } > + if (nb_cpls == 0) { > + RTE_DMADEV_LOG(ERR, "Invalid nb_cpls\n"); > + return -EINVAL; > + } > +#endif > + > + /* Ensure the pointer values are non-null to simplify drivers. > + * In most cases these should be compile time evaluated, since this is > + * an inline function. > + * - If NULL is explicitly passed as parameter, then compiler knows the > + * value is NULL > + * - If address of local variable is passed as parameter, then compiler > + * can know it's non-NULL. > + */ > + if (last_idx == NULL) > + last_idx = &idx; > + if (has_error == NULL) > + has_error = &err; > + > + *has_error = false; > + return (*dev->completed)(dev, vchan, nb_cpls, last_idx, has_error); > +}