From: Jerin Jacob <jerinjacobk@gmail.com>
To: Chengwen Feng <fengchengwen@huawei.com>
Cc: "Thomas Monjalon" <thomas@monjalon.net>,
"Ferruh Yigit" <ferruh.yigit@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Jerin Jacob" <jerinj@marvell.com>, dpdk-dev <dev@dpdk.org>,
"Morten Brørup" <mb@smartsharesystems.com>,
"Nipun Gupta" <nipun.gupta@nxp.com>,
"Hemant Agrawal" <hemant.agrawal@nxp.com>,
"Maxime Coquelin" <maxime.coquelin@redhat.com>,
"Honnappa Nagarahalli" <honnappa.nagarahalli@arm.com>,
"David Marchand" <david.marchand@redhat.com>,
"Satananda Burla" <sburla@marvell.com>,
"Prasun Kapoor" <pkapoor@marvell.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
liangma@liangbit.com,
"Radha Mohan Chintakuntla" <radhac@marvell.com>
Subject: Re: [dpdk-dev] [PATCH] dmadev: introduce DMA device library
Date: Sun, 4 Jul 2021 15:00:30 +0530 [thread overview]
Message-ID: <CALBAE1MOaCv_RPr-JxHBwQibbecYeOyg2_RKPpMySN=UJx=XpA@mail.gmail.com> (raw)
In-Reply-To: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com>
On Fri, Jul 2, 2021 at 6:51 PM Chengwen Feng <fengchengwen@huawei.com> wrote:
>
> This patch introduces '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 <fengchengwen@huawei.com>
Thanks for v1.
I would suggest finalizing lib/dmadev/rte_dmadev.h before doing the
implementation so that you don't need
to waste time on rewoking the implementation.
Comments inline.
> ---
> MAINTAINERS | 4 +
> config/rte_config.h | 3 +
> lib/dmadev/meson.build | 6 +
> lib/dmadev/rte_dmadev.c | 438 +++++++++++++++++++++
> lib/dmadev/rte_dmadev.h | 919 +++++++++++++++++++++++++++++++++++++++++++
> lib/dmadev/rte_dmadev_core.h | 98 +++++
> lib/dmadev/rte_dmadev_pmd.h | 210 ++++++++++
> lib/dmadev/version.map | 32 ++
Missed to update doxygen. See doc/api/doxy-api.conf.in
Use meson -Denable_docs=true to verify the generated doxgen doc.
> lib/meson.build | 1 +
> 9 files changed, 1711 insertions(+)
> create mode 100644 lib/dmadev/meson.build
> create mode 100644 lib/dmadev/rte_dmadev.c
> create mode 100644 lib/dmadev/rte_dmadev.h
> create mode 100644 lib/dmadev/rte_dmadev_core.h
> create mode 100644 lib/dmadev/rte_dmadev_pmd.h
> create mode 100644 lib/dmadev/version.map
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4347555..2019783 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -496,6 +496,10 @@ F: drivers/raw/skeleton/
> F: app/test/test_rawdev.c
> F: doc/guides/prog_guide/rawdev.rst
>
Add EXPERIMENTAL
> +Dma device API
> +M: Chengwen Feng <fengchengwen@huawei.com>
> +F: lib/dmadev/
> +
>
> new file mode 100644
> index 0000000..a94e839
> --- /dev/null
> +++ b/lib/dmadev/rte_dmadev.c
> @@ -0,0 +1,438 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright 2021 HiSilicon Limited.
> + */
> +
> +#include <ctype.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <stdint.h>
> +
> +#include <rte_log.h>
> +#include <rte_debug.h>
> +#include <rte_dev.h>
> +#include <rte_memory.h>
> +#include <rte_memzone.h>
> +#include <rte_malloc.h>
> +#include <rte_errno.h>
> +#include <rte_string_fns.h>
Sort in alphabetical order.
> +
> +#include "rte_dmadev.h"
> +#include "rte_dmadev_pmd.h"
> +
> +struct rte_dmadev rte_dmadevices[RTE_DMADEV_MAX_DEVS];
# Please check have you missed any multiprocess angle.
lib/regexdev/rte_regexdev.c is latest device class implemented in dpdk and
please check *rte_regexdev_shared_data scheme.
# Missing dynamic log for this library.
> diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
> new file mode 100644
> index 0000000..f74fc6a
> --- /dev/null
> +++ b/lib/dmadev/rte_dmadev.h
> @@ -0,0 +1,919 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright 2021 HiSilicon Limited.
It would be nice to add other companies' names who have contributed to
the specification.
> + */
> +
> +#ifndef _RTE_DMADEV_H_
> +#define _RTE_DMADEV_H_
> +
> +/**
> + * @file rte_dmadev.h
> + *
> + * RTE DMA (Direct Memory Access) device APIs.
> + *
> + * The generic DMA device diagram:
> + *
> + * ------------ ------------
> + * | HW-queue | | HW-queue |
> + * ------------ ------------
> + * \ /
> + * \ /
> + * \ /
> + * ----------------
> + * |dma-controller|
> + * ----------------
> + *
> + * The DMA could have multiple HW-queues, each HW-queue could have multiple
> + * capabilities, e.g. whether to support fill operation, supported DMA
> + * transfter direction and etc.
typo
> + *
> + * The DMA framework is built on the following abstraction model:
> + *
> + * ------------ ------------
> + * |virt-queue| |virt-queue|
> + * ------------ ------------
> + * \ /
> + * \ /
> + * \ /
> + * ------------ ------------
> + * | HW-queue | | HW-queue |
> + * ------------ ------------
> + * \ /
> + * \ /
> + * \ /
> + * ----------
> + * | dmadev |
> + * ----------
Continuing the discussion with @Morten Brørup , I think, we need to
finalize the model.
> + * a) The DMA operation request must be submitted to the virt queue, virt
> + * queues must be created based on HW queues, the DMA device could have
> + * multiple HW queues.
> + * b) The virt queues on the same HW-queue could represent different contexts,
> + * e.g. user could create virt-queue-0 on HW-queue-0 for mem-to-mem
> + * transfer scenario, and create virt-queue-1 on the same HW-queue for
> + * mem-to-dev transfer scenario.
> + * NOTE: user could also create multiple virt queues for mem-to-mem transfer
> + * scenario as long as the corresponding driver supports.
> + *
> + * The control plane APIs include configure/queue_setup/queue_release/start/
> + * stop/reset/close, in order to start device work, the call sequence must be
> + * as follows:
> + * - rte_dmadev_configure()
> + * - rte_dmadev_queue_setup()
> + * - rte_dmadev_start()
Please add reconfigure behaviour etc, Please check the
lib/regexdev/rte_regexdev.h
introduction. I have added similar ones so you could reuse as much as possible.
> + * The dataplane APIs include two parts:
> + * a) The first part is the submission of operation requests:
> + * - rte_dmadev_copy()
> + * - rte_dmadev_copy_sg() - scatter-gather form of copy
> + * - rte_dmadev_fill()
> + * - rte_dmadev_fill_sg() - scatter-gather form of fill
> + * - rte_dmadev_fence() - add a fence force ordering between operations
> + * - rte_dmadev_perform() - issue doorbell to hardware
> + * These APIs could work with different virt queues which have different
> + * contexts.
> + * The first four APIs are used to submit the operation request to the virt
> + * queue, if the submission is successful, a cookie (as type
> + * 'dma_cookie_t') is returned, otherwise a negative number is returned.
> + * b) The second part is to obtain the result of requests:
> + * - rte_dmadev_completed()
> + * - return the number of operation requests completed successfully.
> + * - rte_dmadev_completed_fails()
> + * - return the number of operation requests failed to complete.
> + *
> + * The misc APIs include info_get/queue_info_get/stats/xstats/selftest, provide
> + * information query and self-test capabilities.
> + *
> + * About the dataplane APIs MT-safe, there are two dimensions:
> + * a) For one virt queue, the submit/completion API could be MT-safe,
> + * e.g. one thread do submit operation, another thread do completion
> + * operation.
> + * If driver support it, then declare RTE_DMA_DEV_CAPA_MT_VQ.
> + * If driver don't support it, it's up to the application to guarantee
> + * MT-safe.
> + * b) For multiple virt queues on the same HW queue, e.g. one thread do
> + * operation on virt-queue-0, another thread do operation on virt-queue-1.
> + * If driver support it, then declare RTE_DMA_DEV_CAPA_MT_MVQ.
> + * If driver don't support it, it's up to the application to guarantee
> + * MT-safe.
From an application PoV it may not be good to write portable
applications. Please check
latest thread with @Morten Brørup
> + */
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <rte_common.h>
> +#include <rte_memory.h>
> +#include <rte_errno.h>
> +#include <rte_compat.h>
Sort in alphabetical order.
> +
> +/**
> + * dma_cookie_t - an opaque DMA cookie
Since we are defining the behaviour is not opaque any more.
I think, it is better to call ring_idx or so.
> +#define RTE_DMA_DEV_CAPA_MT_MVQ (1ull << 11) /**< Support MT-safe of multiple virt queues */
Please lot of @see for all symbols where it is being used. So that one
can understand the full scope of
symbols. See below example.
#define RTE_REGEXDEV_CAPA_RUNTIME_COMPILATION_F (1ULL << 0)
/**< RegEx device does support compiling the rules at runtime unlike
* loading only the pre-built rule database using
* struct rte_regexdev_config::rule_db in rte_regexdev_configure()
*
* @see struct rte_regexdev_config::rule_db, rte_regexdev_configure()
* @see struct rte_regexdev_info::regexdev_capa
*/
> + *
> + * If dma_cookie_t is >=0 it's a DMA operation request cookie, <0 it's a error
> + * code.
> + * When using cookies, comply with the following rules:
> + * a) Cookies for each virtual queue are independent.
> + * b) For a virt queue, the cookie are monotonically incremented, when it reach
> + * the INT_MAX, it wraps back to zero.
> + * c) The initial cookie of a virt queue is zero, after the device is stopped or
> + * reset, the virt queue's cookie needs to be reset to zero.
> + * Example:
> + * step-1: start one dmadev
> + * step-2: enqueue a copy operation, the cookie return is 0
> + * step-3: enqueue a copy operation again, the cookie return is 1
> + * ...
> + * step-101: stop the dmadev
> + * step-102: start the dmadev
> + * step-103: enqueue a copy operation, the cookie return is 0
> + * ...
> + */
Good explanation.
> +typedef int32_t dma_cookie_t;
> +
> +/**
> + * dma_scatterlist - can hold scatter DMA operation request
> + */
> +struct dma_scatterlist {
I prefer to change scatterlist -> sg
i.e rte_dma_sg
> + void *src;
> + void *dst;
> + uint32_t length;
> +};
> +
> +
> +/**
> + * A structure used to retrieve the contextual information of
> + * an DMA device
> + */
> +struct rte_dmadev_info {
> + /**
> + * Fields filled by framewok
typo.
> + */
> + struct rte_device *device; /**< Generic Device information */
> + const char *driver_name; /**< Device driver name */
> + int socket_id; /**< Socket ID where memory is allocated */
> +
> + /**
> + * Specification fields filled by driver
> + */
> + uint64_t dev_capa; /**< Device capabilities (RTE_DMA_DEV_CAPA_) */
> + uint16_t max_hw_queues; /**< Maximum number of HW queues. */
> + uint16_t max_vqs_per_hw_queue;
> + /**< Maximum number of virt queues to allocate per HW queue */
> + uint16_t max_desc;
> + /**< Maximum allowed number of virt queue descriptors */
> + uint16_t min_desc;
> + /**< Minimum allowed number of virt queue descriptors */
Please add max_nb_segs. i.e maximum number of segments supported.
> +
> + /**
> + * Status fields filled by driver
> + */
> + uint16_t nb_hw_queues; /**< Number of HW queues configured */
> + uint16_t nb_vqs; /**< Number of virt queues configured */
> +};
> + i
> +
> +/**
> + * dma_address_type
> + */
> +enum dma_address_type {
> + DMA_ADDRESS_TYPE_IOVA, /**< Use IOVA as dma address */
> + DMA_ADDRESS_TYPE_VA, /**< Use VA as dma address */
> +};
> +
> +/**
> + * A structure used to configure a DMA device.
> + */
> +struct rte_dmadev_conf {
> + enum dma_address_type addr_type; /**< Address type to used */
I think, there are 3 kinds of limitations/capabilities.
When the system is configured as IOVA as VA
1) Device supports any VA address like memory from rte_malloc(),
rte_memzone(), malloc, stack memory
2) Device support only VA address from rte_malloc(), rte_memzone() i.e
memory backed by hugepage and added to DMA map.
When the system is configured as IOVA as PA
1) Devices support only PA addresses .
IMO, Above needs to be advertised as capability and application needs
to align with that
and I dont think application requests the driver to work in any of the modes.
> + uint16_t nb_hw_queues; /**< Number of HW-queues enable to use */
> + uint16_t max_vqs; /**< Maximum number of virt queues to use */
You need to what is max value allowed etc i.e it is based on
info_get() and mention the field
in info structure
> +
> +/**
> + * dma_transfer_direction
> + */
> +enum dma_transfer_direction {
rte_dma_transter_direction
> + DMA_MEM_TO_MEM,
> + DMA_MEM_TO_DEV,
> + DMA_DEV_TO_MEM,
> + DMA_DEV_TO_DEV,
> +};
> +
> +/**
> + * A structure used to configure a DMA virt queue.
> + */
> +struct rte_dmadev_queue_conf {
> + enum dma_transfer_direction direction;
> + /**< Associated transfer direction */
> + uint16_t hw_queue_id; /**< The HW queue on which to create virt queue */
> + uint16_t nb_desc; /**< Number of descriptor for this virt queue */
> + uint64_t dev_flags; /**< Device specific flags */
Use of this? Need more comments on this.
Since it is in slowpath, We can have non opaque names here based on
each driver capability.
> + void *dev_ctx; /**< Device specific context */
Use of this ? Need more comment ont this.
Please add some good amount of reserved bits and have API to init this
structure for future ABI stability, say rte_dmadev_queue_config_init()
or so.
> +
> +/**
> + * A structure used to retrieve information of a DMA virt queue.
> + */
> +struct rte_dmadev_queue_info {
> + enum dma_transfer_direction direction;
A queue may support all directions so I think it should be a bitfield.
> + /**< Associated transfer direction */
> + uint16_t hw_queue_id; /**< The HW queue on which to create virt queue */
> + uint16_t nb_desc; /**< Number of descriptor for this virt queue */
> + uint64_t dev_flags; /**< Device specific flags */
> +};
> +
> +__rte_experimental
> +static inline dma_cookie_t
> +rte_dmadev_copy_sg(uint16_t dev_id, uint16_t vq_id,
> + const struct dma_scatterlist *sg,
> + uint32_t sg_len, uint64_t flags)
I would like to change this as:
rte_dmadev_copy_sg(uint16_t dev_id, uint16_t vq_id, const struct
rte_dma_sg *src, uint32_t nb_src,
const struct rte_dma_sg *dst, uint32_t nb_dst) or so allow the use case like
src 30 MB copy can be splitted as written as 1 MB x 30 dst.
> +{
> + struct rte_dmadev *dev = &rte_dmadevices[dev_id];
> + return (*dev->copy_sg)(dev, vq_id, sg, sg_len, flags);
> +}
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Enqueue a fill operation onto the DMA virt queue
> + *
> + * 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 vq_id
> + * The identifier of virt queue.
> + * @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 opaque flags for this operation.
PLEASE REMOVE opaque stuff from fastpath it will be a pain for
application writers as
they need to write multiple combinations of fastpath. flags are OK, if
we have a valid
generic flag now to control the transfer behavior.
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Add a fence to force ordering between operations
> + *
> + * This adds a fence to a sequence of operations to enforce ordering, such that
> + * all operations enqueued before the fence must be completed before operations
> + * after the fence.
> + * NOTE: Since this fence may be added as a flag to the last operation enqueued,
> + * this API may not function correctly when called immediately after an
> + * "rte_dmadev_perform" call i.e. before any new operations are enqueued.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param vq_id
> + * The identifier of virt queue.
> + *
> + * @return
> + * - =0: Successful add fence.
> + * - <0: Failure to add fence.
> + *
> + * NOTE: The caller must ensure that the input parameter is valid and the
> + * corresponding device supports the operation.
> + */
> +__rte_experimental
> +static inline int
> +rte_dmadev_fence(uint16_t dev_id, uint16_t vq_id)
> +{
> + struct rte_dmadev *dev = &rte_dmadevices[dev_id];
> + return (*dev->fence)(dev, vq_id);
> +}
Since HW submission is in a queue(FIFO) the ordering is always
maintained. Right?
Could you share more details and use case of fence() from
driver/application PoV?
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Trigger hardware to begin performing enqueued operations
> + *
> + * This API is used to write the "doorbell" to the hardware to trigger it
> + * to begin the operations previously enqueued by rte_dmadev_copy/fill()
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param vq_id
> + * The identifier of virt queue.
> + *
> + * @return
> + * - =0: Successful trigger hardware.
> + * - <0: Failure to trigger hardware.
> + *
> + * NOTE: The caller must ensure that the input parameter is valid and the
> + * corresponding device supports the operation.
> + */
> +__rte_experimental
> +static inline int
> +rte_dmadev_perform(uint16_t dev_id, uint16_t vq_id)
> +{
> + struct rte_dmadev *dev = &rte_dmadevices[dev_id];
> + return (*dev->perform)(dev, vq_id);
> +}
Since we have additional function call overhead in all the
applications for this scheme, I would like to understand
the use of doing this way vs enq does the doorbell implicitly from
driver/application PoV?
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Returns the number of operations that have been successful completed.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param vq_id
> + * The identifier of virt queue.
> + * @param nb_cpls
> + * The maximum number of completed operations that can be processed.
> + * @param[out] cookie
> + * The last completed operation's cookie.
> + * @param[out] has_error
> + * Indicates if there are transfer error.
> + *
> + * @return
> + * The number of operations that successful completed.
successfully
> + *
> + * NOTE: The caller must ensure that the input parameter is valid and the
> + * corresponding device supports the operation.
> + */
> +__rte_experimental
> +static inline uint16_t
> +rte_dmadev_completed(uint16_t dev_id, uint16_t vq_id, const uint16_t nb_cpls,
> + dma_cookie_t *cookie, bool *has_error)
> +{
> + struct rte_dmadev *dev = &rte_dmadevices[dev_id];
> + has_error = false;
> + return (*dev->completed)(dev, vq_id, nb_cpls, cookie, has_error);
It may be better to have cookie/ring_idx as third argument.
> +}
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Returns the number of operations that failed to complete.
> + * NOTE: This API was used when rte_dmadev_completed has_error was set.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param vq_id
> + * The identifier of virt queue.
(> + * @param nb_status
> + * Indicates the size of status array.
> + * @param[out] status
> + * The error code of operations that failed to complete.
> + * @param[out] cookie
> + * The last failed completed operation's cookie.
> + *
> + * @return
> + * The number of operations that failed to complete.
> + *
> + * NOTE: The caller must ensure that the input parameter is valid and the
> + * corresponding device supports the operation.
> + */
> +__rte_experimental
> +static inline uint16_t
> +rte_dmadev_completed_fails(uint16_t dev_id, uint16_t vq_id,
> + const uint16_t nb_status, uint32_t *status,
> + dma_cookie_t *cookie)
IMO, it is better to move cookie/rind_idx at 3.
Why it would return any array of errors? since it called after
rte_dmadev_completed() has
has_error. Is it better to change
rte_dmadev_error_status((uint16_t dev_id, uint16_t vq_id, dma_cookie_t
*cookie, uint32_t *status)
I also think, we may need to set status as bitmask and enumerate all
the combination of error codes
of all the driver and return string from driver existing rte_flow_error
See
struct rte_flow_error {
enum rte_flow_error_type type; /**< Cause field and error types. */
const void *cause; /**< Object responsible for the error. */
const char *message; /**< Human-readable error message. */
};
> +{
> + struct rte_dmadev *dev = &rte_dmadevices[dev_id];
> + return (*dev->completed_fails)(dev, vq_id, nb_status, status, cookie);
> +}
> +
> +struct rte_dmadev_stats {
> + uint64_t enqueue_fail_count;
> + /**< Conut of all operations which failed enqueued */
> + uint64_t enqueued_count;
> + /**< Count of all operations which successful enqueued */
> + uint64_t completed_fail_count;
> + /**< Count of all operations which failed to complete */
> + uint64_t completed_count;
> + /**< Count of all operations which successful complete */
> +};
We need to have capability API to tell which items are
updated/supported by the driver.
> diff --git a/lib/dmadev/rte_dmadev_core.h b/lib/dmadev/rte_dmadev_core.h
> new file mode 100644
> index 0000000..a3afea2
> --- /dev/null
> +++ b/lib/dmadev/rte_dmadev_core.h
> @@ -0,0 +1,98 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright 2021 HiSilicon Limited.
> + */
> +
> +#ifndef _RTE_DMADEV_CORE_H_
> +#define _RTE_DMADEV_CORE_H_
> +
> +/**
> + * @file
> + *
> + * RTE DMA Device internal header.
> + *
> + * This header contains internal data types. But they are still part of the
> + * public API because they are used by inline public functions.
> + */
> +
> +struct rte_dmadev;
> +
> +typedef dma_cookie_t (*dmadev_copy_t)(struct rte_dmadev *dev, uint16_t vq_id,
> + void *src, void *dst,
> + uint32_t length, uint64_t flags);
> +/**< @internal Function used to enqueue a copy operation. */
To avoid namespace conflict(as it is public API) use rte_
> +
> +/**
> + * The data structure associated with each DMA device.
> + */
> +struct rte_dmadev {
> + /**< Enqueue a copy operation onto the DMA device. */
> + dmadev_copy_t copy;
> + /**< Enqueue a scatter list copy operation onto the DMA device. */
> + dmadev_copy_sg_t copy_sg;
> + /**< Enqueue a fill operation onto the DMA device. */
> + dmadev_fill_t fill;
> + /**< Enqueue a scatter list fill operation onto the DMA device. */
> + dmadev_fill_sg_t fill_sg;
> + /**< Add a fence to force ordering between operations. */
> + dmadev_fence_t fence;
> + /**< Trigger hardware to begin performing enqueued operations. */
> + dmadev_perform_t perform;
> + /**< Returns the number of operations that successful completed. */
> + dmadev_completed_t completed;
> + /**< Returns the number of operations that failed to complete. */
> + dmadev_completed_fails_t completed_fails;
We need to limit fastpath items in 1 CL
> +
> + void *dev_private; /**< PMD-specific private data */
> + const struct rte_dmadev_ops *dev_ops; /**< Functions exported by PMD */
> +
> + uint16_t dev_id; /**< Device ID for this instance */
> + int socket_id; /**< Socket ID where memory is allocated */
> + struct rte_device *device;
> + /**< Device info. supplied during device initialization */
> + const char *driver_name; /**< Driver info. supplied by probing */
> + char name[RTE_DMADEV_NAME_MAX_LEN]; /**< Device name */
> +
> + RTE_STD_C11
> + uint8_t attached : 1; /**< Flag indicating the device is attached */
> + uint8_t started : 1; /**< Device state: STARTED(1)/STOPPED(0) */
Add a couple of reserved fields for future ABI stability.
> +
> +} __rte_cache_aligned;
> +
> +extern struct rte_dmadev rte_dmadevices[];
> +
next prev parent reply other threads:[~2021-07-04 9:30 UTC|newest]
Thread overview: 339+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 13:18 Chengwen Feng
2021-07-02 13:59 ` Bruce Richardson
2021-07-04 9:30 ` Jerin Jacob [this message]
2021-07-05 10:52 ` Bruce Richardson
2021-07-05 11:12 ` Morten Brørup
2021-07-05 13:44 ` Bruce Richardson
2021-07-05 15:55 ` Jerin Jacob
2021-07-05 17:16 ` Bruce Richardson
2021-07-07 8:08 ` Jerin Jacob
2021-07-07 8:35 ` Bruce Richardson
2021-07-07 10:34 ` Jerin Jacob
2021-07-07 11:01 ` Bruce Richardson
2021-07-08 3:11 ` fengchengwen
2021-07-08 18:35 ` Jerin Jacob
2021-07-09 9:14 ` Bruce Richardson
2021-07-11 7:14 ` Jerin Jacob
2021-07-12 7:01 ` Morten Brørup
2021-07-12 7:59 ` Jerin Jacob
2021-07-06 8:20 ` fengchengwen
2021-07-06 9:27 ` Bruce Richardson
2021-07-06 3:01 ` fengchengwen
2021-07-06 10:01 ` Bruce Richardson
2021-07-04 14:57 ` Andrew Rybchenko
2021-07-06 3:56 ` fengchengwen
2021-07-06 10:02 ` Bruce Richardson
2021-07-04 15:21 ` Matan Azrad
2021-07-06 6:25 ` fengchengwen
2021-07-06 6:50 ` Matan Azrad
2021-07-06 9:08 ` fengchengwen
2021-07-06 9:17 ` Matan Azrad
2021-07-06 20:28 ` [dpdk-dev] [RFC UPDATE PATCH 0/9] dmadev rfc suggested updates Bruce Richardson
2021-07-06 20:28 ` [dpdk-dev] [RFC UPDATE PATCH 1/9] dmadev: add missing exports Bruce Richardson
2021-07-07 8:26 ` David Marchand
2021-07-07 8:36 ` Bruce Richardson
2021-07-07 8:57 ` David Marchand
2021-07-06 20:28 ` [dpdk-dev] [RFC UPDATE PATCH 2/9] dmadev: change virtual addresses to IOVA Bruce Richardson
2021-07-06 20:28 ` [dpdk-dev] [RFC UPDATE PATCH 3/9] dmadev: add dump function Bruce Richardson
2021-07-06 20:28 ` [dpdk-dev] [RFC UPDATE PATCH 4/9] dmadev: remove xstats functions Bruce Richardson
2021-07-06 20:28 ` [dpdk-dev] [RFC UPDATE PATCH 5/9] dmadev: drop cookie typedef Bruce Richardson
2021-07-06 20:28 ` [dpdk-dev] [RFC UPDATE PATCH 6/9] dmadev: allow NULL parameters to completed ops call Bruce Richardson
2021-07-06 20:28 ` [dpdk-dev] [RFC UPDATE PATCH 7/9] dmadev: stats structure updates Bruce Richardson
2021-07-06 20:28 ` [dpdk-dev] [RFC UPDATE PATCH 8/9] drivers: add dma driver category Bruce Richardson
2021-07-06 20:28 ` [dpdk-dev] [RFC UPDATE PATCH 9/9] app/test: add basic dmadev unit test Bruce Richardson
2021-07-07 3:16 ` [dpdk-dev] [RFC UPDATE PATCH 0/9] dmadev rfc suggested updates fengchengwen
2021-07-07 8:11 ` Bruce Richardson
2021-07-07 8:14 ` Bruce Richardson
2021-07-07 10:42 ` Jerin Jacob
2021-07-11 9:25 ` [dpdk-dev] [PATCH v2] dmadev: introduce DMA device library Chengwen Feng
2021-07-11 9:42 ` fengchengwen
2021-07-11 13:34 ` Jerin Jacob
2021-07-12 7:40 ` Morten Brørup
2021-07-11 14:25 ` Jerin Jacob
2021-07-12 7:15 ` Morten Brørup
2021-07-12 9:59 ` Jerin Jacob
2021-07-12 13:32 ` Bruce Richardson
2021-07-12 16:34 ` Jerin Jacob
2021-07-12 17:00 ` Bruce Richardson
2021-07-13 8:59 ` Jerin Jacob
2021-07-12 12:05 ` Bruce Richardson
2021-07-12 15:50 ` Bruce Richardson
2021-07-13 9:07 ` Jerin Jacob
2021-07-13 14:19 ` Ananyev, Konstantin
2021-07-13 14:28 ` Bruce Richardson
2021-07-13 12:27 ` [dpdk-dev] [PATCH v3] " Chengwen Feng
2021-07-13 13:06 ` fengchengwen
2021-07-13 13:37 ` Bruce Richardson
2021-07-15 6:44 ` Jerin Jacob
2021-07-15 8:25 ` Bruce Richardson
2021-07-15 9:49 ` Jerin Jacob
2021-07-15 10:00 ` Bruce Richardson
2021-07-13 16:02 ` Bruce Richardson
2021-07-14 12:22 ` Nipun Gupta
2021-07-15 8:29 ` fengchengwen
2021-07-15 11:16 ` Nipun Gupta
2021-07-15 12:11 ` Bruce Richardson
2021-07-15 12:31 ` Jerin Jacob
2021-07-15 12:34 ` Nipun Gupta
2021-07-14 16:05 ` Bruce Richardson
2021-07-15 7:10 ` Jerin Jacob
2021-07-15 9:03 ` Bruce Richardson
2021-07-15 9:30 ` Jerin Jacob
2021-07-15 10:03 ` Bruce Richardson
2021-07-15 10:05 ` Bruce Richardson
2021-07-15 15:41 ` [dpdk-dev] [PATCH v4] " Chengwen Feng
2021-07-15 16:04 ` fengchengwen
2021-07-15 16:33 ` Bruce Richardson
2021-07-16 3:04 ` fengchengwen
2021-07-16 9:50 ` Bruce Richardson
2021-07-16 12:34 ` Jerin Jacob
2021-07-16 12:40 ` Jerin Jacob
2021-07-16 12:48 ` Bruce Richardson
2021-07-16 12:54 ` Jerin Jacob
2021-07-16 2:45 ` [dpdk-dev] [PATCH v5] " Chengwen Feng
2021-07-16 13:20 ` Jerin Jacob
2021-07-16 14:41 ` Bruce Richardson
2021-07-19 3:29 ` [dpdk-dev] [PATCH v6] " Chengwen Feng
2021-07-19 6:21 ` Jerin Jacob
2021-07-19 13:20 ` fengchengwen
2021-07-19 13:36 ` Jerin Jacob
2021-07-19 13:05 ` [dpdk-dev] [PATCH v7] " Chengwen Feng
2021-07-20 1:14 ` [dpdk-dev] [PATCH v8] " Chengwen Feng
2021-07-20 5:03 ` Jerin Jacob
2021-07-20 6:53 ` fengchengwen
2021-07-20 9:43 ` Jerin Jacob
2021-07-20 10:13 ` Bruce Richardson
2021-07-20 11:12 ` [dpdk-dev] [PATCH v9] " Chengwen Feng
2021-07-20 12:05 ` Bruce Richardson
2021-07-20 12:46 ` [dpdk-dev] [PATCH v10] " Chengwen Feng
2021-07-26 6:53 ` fengchengwen
2021-07-26 8:31 ` Bruce Richardson
2021-07-27 3:57 ` fengchengwen
2021-07-26 11:03 ` Morten Brørup
2021-07-26 11:21 ` Jerin Jacob
2021-07-27 3:39 ` [dpdk-dev] [PATCH v11 0/2] support dmadev Chengwen Feng
2021-07-27 3:39 ` [dpdk-dev] [PATCH v11 1/2] dmadev: introduce DMA device library Chengwen Feng
2021-07-28 11:13 ` Bruce Richardson
2021-07-29 1:26 ` fengchengwen
2021-07-29 9:15 ` Bruce Richardson
2021-07-29 13:33 ` fengchengwen
2021-07-29 10:44 ` Jerin Jacob
2021-07-29 13:30 ` fengchengwen
2021-07-27 3:40 ` [dpdk-dev] [PATCH v11 2/2] doc: add dmadev library guide Chengwen Feng
2021-07-29 11:02 ` Jerin Jacob
2021-07-29 13:13 ` fengchengwen
2021-07-29 13:28 ` fengchengwen
2021-07-29 13:06 ` [dpdk-dev] [PATCH v12 0/6] support dmadev Chengwen Feng
2021-07-29 13:06 ` [dpdk-dev] [PATCH v12 1/6] dmadev: introduce DMA device library public APIs Chengwen Feng
2021-07-29 13:06 ` [dpdk-dev] [PATCH v12 2/6] dmadev: introduce DMA device library internal header Chengwen Feng
2021-07-29 13:06 ` [dpdk-dev] [PATCH v12 3/6] dmadev: introduce DMA device library PMD header Chengwen Feng
2021-07-29 13:06 ` [dpdk-dev] [PATCH v12 4/6] dmadev: introduce DMA device library implementation Chengwen Feng
2021-07-29 13:06 ` [dpdk-dev] [PATCH v12 5/6] doc: add DMA device library guide Chengwen Feng
2021-07-29 13:06 ` [dpdk-dev] [PATCH v12 6/6] maintainers: add for dmadev Chengwen Feng
2021-08-03 11:29 ` [dpdk-dev] [PATCH v13 0/6] support dmadev Chengwen Feng
2021-08-03 11:29 ` [dpdk-dev] [PATCH v13 1/6] dmadev: introduce DMA device library public APIs Chengwen Feng
2021-08-03 11:29 ` [dpdk-dev] [PATCH v13 2/6] dmadev: introduce DMA device library internal header Chengwen Feng
2021-08-03 11:29 ` [dpdk-dev] [PATCH v13 3/6] dmadev: introduce DMA device library PMD header Chengwen Feng
2021-08-03 11:29 ` [dpdk-dev] [PATCH v13 4/6] dmadev: introduce DMA device library implementation Chengwen Feng
2021-08-05 12:56 ` Walsh, Conor
2021-08-05 13:12 ` fengchengwen
2021-08-05 13:44 ` Conor Walsh
2021-08-03 11:29 ` [dpdk-dev] [PATCH v13 5/6] doc: add DMA device library guide Chengwen Feng
2021-08-03 14:55 ` Jerin Jacob
2021-08-05 13:15 ` fengchengwen
2021-08-03 11:29 ` [dpdk-dev] [PATCH v13 6/6] maintainers: add for dmadev Chengwen Feng
2021-08-03 11:46 ` [dpdk-dev] [PATCH v13 0/6] support dmadev fengchengwen
2021-08-10 11:54 ` [dpdk-dev] [PATCH v14 " Chengwen Feng
2021-08-10 11:54 ` [dpdk-dev] [PATCH v14 1/6] dmadev: introduce DMA device library public APIs Chengwen Feng
2021-08-10 11:54 ` [dpdk-dev] [PATCH v14 2/6] dmadev: introduce DMA device library internal header Chengwen Feng
2021-08-10 11:54 ` [dpdk-dev] [PATCH v14 3/6] dmadev: introduce DMA device library PMD header Chengwen Feng
2021-08-10 11:54 ` [dpdk-dev] [PATCH v14 4/6] dmadev: introduce DMA device library implementation Chengwen Feng
2021-08-10 11:54 ` [dpdk-dev] [PATCH v14 5/6] doc: add DMA device library guide Chengwen Feng
2021-08-10 15:27 ` Walsh, Conor
2021-08-11 0:47 ` fengchengwen
2021-08-13 9:20 ` fengchengwen
2021-08-13 10:12 ` Walsh, Conor
2021-08-10 11:54 ` [dpdk-dev] [PATCH v14 6/6] maintainers: add for dmadev Chengwen Feng
2021-08-13 9:09 ` [dpdk-dev] [PATCH v15 0/6] support dmadev Chengwen Feng
2021-08-13 9:09 ` [dpdk-dev] [PATCH v15 1/6] dmadev: introduce DMA device library public APIs Chengwen Feng
2021-08-19 14:52 ` Bruce Richardson
2021-08-23 3:43 ` fengchengwen
2021-08-13 9:09 ` [dpdk-dev] [PATCH v15 2/6] dmadev: introduce DMA device library internal header Chengwen Feng
2021-08-13 9:09 ` [dpdk-dev] [PATCH v15 3/6] dmadev: introduce DMA device library PMD header Chengwen Feng
2021-08-13 9:09 ` [dpdk-dev] [PATCH v15 4/6] dmadev: introduce DMA device library implementation Chengwen Feng
2021-08-13 9:09 ` [dpdk-dev] [PATCH v15 5/6] doc: add DMA device library guide Chengwen Feng
2021-08-13 9:09 ` [dpdk-dev] [PATCH v15 6/6] maintainers: add for dmadev Chengwen Feng
2021-08-23 3:31 ` [dpdk-dev] [PATCH v16 0/9] support dmadev Chengwen Feng
2021-08-23 3:31 ` [dpdk-dev] [PATCH v16 1/9] dmadev: introduce DMA device library public APIs Chengwen Feng
2021-08-23 3:31 ` [dpdk-dev] [PATCH v16 2/9] dmadev: introduce DMA device library internal header Chengwen Feng
2021-08-23 3:31 ` [dpdk-dev] [PATCH v16 3/9] dmadev: introduce DMA device library PMD header Chengwen Feng
2021-08-23 3:31 ` [dpdk-dev] [PATCH v16 4/9] dmadev: introduce DMA device library implementation Chengwen Feng
2021-08-23 3:31 ` [dpdk-dev] [PATCH v16 5/9] doc: add DMA device library guide Chengwen Feng
2021-08-23 3:31 ` [dpdk-dev] [PATCH v16 6/9] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-08-26 18:39 ` Bruce Richardson
2021-08-23 3:31 ` [dpdk-dev] [PATCH v16 7/9] dma/skeleton: add test cases Chengwen Feng
2021-08-23 14:03 ` Bruce Richardson
2021-08-26 9:30 ` fengchengwen
2021-08-23 3:31 ` [dpdk-dev] [PATCH v16 8/9] test: enable dmadev skeleton test Chengwen Feng
2021-08-23 3:31 ` [dpdk-dev] [PATCH v16 9/9] maintainers: add for dmadev Chengwen Feng
2021-08-28 7:29 ` [dpdk-dev] [PATCH v17 0/8] support dmadev Chengwen Feng
2021-08-28 7:29 ` [dpdk-dev] [PATCH v17 1/8] dmadev: introduce DMA device library public APIs Chengwen Feng
2021-08-28 7:30 ` [dpdk-dev] [PATCH v17 2/8] dmadev: introduce DMA device library internal header Chengwen Feng
2021-08-28 7:30 ` [dpdk-dev] [PATCH v17 3/8] dmadev: introduce DMA device library PMD header Chengwen Feng
2021-08-28 7:30 ` [dpdk-dev] [PATCH v17 4/8] dmadev: introduce DMA device library implementation Chengwen Feng
2021-08-28 7:30 ` [dpdk-dev] [PATCH v17 5/8] doc: add DMA device library guide Chengwen Feng
2021-08-28 7:30 ` [dpdk-dev] [PATCH v17 6/8] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-08-28 7:30 ` [dpdk-dev] [PATCH v17 7/8] app/test: add dmadev API test Chengwen Feng
2021-08-28 7:30 ` [dpdk-dev] [PATCH v17 8/8] maintainers: add for dmadev Chengwen Feng
2021-08-28 8:25 ` fengchengwen
2021-08-30 8:19 ` Bruce Richardson
2021-09-02 10:54 ` [dpdk-dev] [PATCH v18 0/8] support dmadev Chengwen Feng
2021-09-02 10:54 ` [dpdk-dev] [PATCH v18 1/8] dmadev: introduce DMA device library public APIs Chengwen Feng
2021-09-02 10:54 ` [dpdk-dev] [PATCH v18 2/8] dmadev: introduce DMA device library internal header Chengwen Feng
2021-09-02 10:54 ` [dpdk-dev] [PATCH v18 3/8] dmadev: introduce DMA device library PMD header Chengwen Feng
2021-09-02 10:54 ` [dpdk-dev] [PATCH v18 4/8] dmadev: introduce DMA device library implementation Chengwen Feng
2021-09-02 10:54 ` [dpdk-dev] [PATCH v18 5/8] doc: add DMA device library guide Chengwen Feng
2021-09-02 10:54 ` [dpdk-dev] [PATCH v18 6/8] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-09-02 10:54 ` [dpdk-dev] [PATCH v18 7/8] app/test: add dmadev API test Chengwen Feng
2021-09-02 10:54 ` [dpdk-dev] [PATCH v18 8/8] maintainers: add for dmadev Chengwen Feng
2021-09-02 11:51 ` Bruce Richardson
2021-09-02 13:39 ` fengchengwen
2021-09-03 12:59 ` Maxime Coquelin
2021-09-04 7:02 ` fengchengwen
2021-09-06 1:46 ` Li, Xiaoyun
2021-09-06 8:00 ` fengchengwen
2021-09-06 2:03 ` Xia, Chenbo
2021-09-06 8:01 ` fengchengwen
2021-09-02 13:13 ` [dpdk-dev] [PATCH v19 0/7] support dmadev Chengwen Feng
2021-09-02 13:13 ` [dpdk-dev] [PATCH v19 1/7] dmadev: introduce DMA device library public APIs Chengwen Feng
2021-09-03 11:42 ` Gagandeep Singh
2021-09-04 1:31 ` fengchengwen
2021-09-06 6:48 ` Gagandeep Singh
2021-09-06 7:52 ` fengchengwen
2021-09-06 8:06 ` Jerin Jacob
2021-09-06 8:08 ` Bruce Richardson
2021-09-07 12:55 ` fengchengwen
2021-09-03 13:03 ` Bruce Richardson
2021-09-04 3:05 ` fengchengwen
2021-09-04 10:10 ` Morten Brørup
2021-09-03 15:13 ` Kevin Laatz
2021-09-03 15:35 ` Conor Walsh
2021-09-02 13:13 ` [dpdk-dev] [PATCH v19 2/7] dmadev: introduce DMA device library internal header Chengwen Feng
2021-09-03 15:13 ` Kevin Laatz
2021-09-03 15:35 ` Conor Walsh
2021-09-02 13:13 ` [dpdk-dev] [PATCH v19 3/7] dmadev: introduce DMA device library PMD header Chengwen Feng
2021-09-03 15:13 ` Kevin Laatz
2021-09-03 15:35 ` Conor Walsh
2021-09-02 13:13 ` [dpdk-dev] [PATCH v19 4/7] dmadev: introduce DMA device library implementation Chengwen Feng
2021-09-03 15:13 ` Kevin Laatz
2021-09-03 15:30 ` Bruce Richardson
2021-09-03 15:35 ` Conor Walsh
2021-09-04 8:52 ` fengchengwen
2021-09-02 13:13 ` [dpdk-dev] [PATCH v19 5/7] doc: add DMA device library guide Chengwen Feng
2021-09-03 15:13 ` Kevin Laatz
2021-09-02 13:13 ` [dpdk-dev] [PATCH v19 6/7] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-09-03 15:14 ` Kevin Laatz
2021-09-04 7:17 ` fengchengwen
2021-09-03 15:36 ` Conor Walsh
2021-09-02 13:13 ` [dpdk-dev] [PATCH v19 7/7] app/test: add dmadev API test Chengwen Feng
2021-09-02 14:11 ` Walsh, Conor
2021-09-03 0:39 ` fengchengwen
2021-09-03 15:38 ` Walsh, Conor
2021-09-04 7:22 ` fengchengwen
2021-09-03 15:14 ` Kevin Laatz
2021-09-04 10:10 ` [dpdk-dev] [PATCH v20 0/7] support dmadev Chengwen Feng
2021-09-04 10:10 ` [dpdk-dev] [PATCH v20 1/7] dmadev: introduce DMA device library public APIs Chengwen Feng
2021-09-04 10:10 ` [dpdk-dev] [PATCH v20 2/7] dmadev: introduce DMA device library internal header Chengwen Feng
2021-09-06 13:35 ` Bruce Richardson
2021-09-07 13:05 ` fengchengwen
2021-09-04 10:10 ` [dpdk-dev] [PATCH v20 3/7] dmadev: introduce DMA device library PMD header Chengwen Feng
2021-09-04 10:10 ` [dpdk-dev] [PATCH v20 4/7] dmadev: introduce DMA device library implementation Chengwen Feng
2021-09-04 10:10 ` [dpdk-dev] [PATCH v20 5/7] doc: add DMA device library guide Chengwen Feng
2021-09-04 10:17 ` Jerin Jacob
2021-09-04 10:10 ` [dpdk-dev] [PATCH v20 6/7] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-09-04 10:10 ` [dpdk-dev] [PATCH v20 7/7] app/test: add dmadev API test Chengwen Feng
2021-09-06 13:37 ` [dpdk-dev] [PATCH v20 0/7] support dmadev Bruce Richardson
2021-09-07 12:56 ` [dpdk-dev] [PATCH v21 " Chengwen Feng
2021-09-07 12:56 ` [dpdk-dev] [PATCH v21 1/7] dmadev: introduce DMA device library public APIs Chengwen Feng
2021-09-09 10:33 ` Thomas Monjalon
2021-09-09 11:18 ` Bruce Richardson
2021-09-09 11:29 ` Thomas Monjalon
2021-09-09 12:45 ` Bruce Richardson
2021-09-09 13:54 ` fengchengwen
2021-09-09 14:26 ` Thomas Monjalon
2021-09-09 14:31 ` Bruce Richardson
2021-09-09 14:28 ` Bruce Richardson
2021-09-09 15:12 ` Morten Brørup
2021-09-09 13:33 ` fengchengwen
2021-09-09 14:19 ` Thomas Monjalon
2021-09-16 3:57 ` fengchengwen
2021-09-07 12:56 ` [dpdk-dev] [PATCH v21 2/7] dmadev: introduce DMA device library internal header Chengwen Feng
2021-09-07 12:56 ` [dpdk-dev] [PATCH v21 3/7] dmadev: introduce DMA device library PMD header Chengwen Feng
2021-09-07 12:56 ` [dpdk-dev] [PATCH v21 4/7] dmadev: introduce DMA device library implementation Chengwen Feng
2021-09-08 9:54 ` Walsh, Conor
2021-09-09 13:25 ` fengchengwen
2021-09-15 13:51 ` Kevin Laatz
2021-09-15 14:34 ` Bruce Richardson
2021-09-15 14:47 ` Kevin Laatz
2021-09-07 12:56 ` [dpdk-dev] [PATCH v21 5/7] doc: add DMA device library guide Chengwen Feng
2021-09-07 12:56 ` [dpdk-dev] [PATCH v21 6/7] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-09-07 12:56 ` [dpdk-dev] [PATCH v21 7/7] app/test: add dmadev API test Chengwen Feng
2021-09-16 3:41 ` [dpdk-dev] [PATCH v22 0/5] support dmadev Chengwen Feng
2021-09-16 3:41 ` [dpdk-dev] [PATCH v22 1/5] dmadev: introduce DMA device library Chengwen Feng
2021-09-16 3:41 ` [dpdk-dev] [PATCH v22 2/5] dmadev: add control plane function support Chengwen Feng
2021-09-16 3:41 ` [dpdk-dev] [PATCH v22 3/5] dmadev: add data " Chengwen Feng
2021-09-16 3:41 ` [dpdk-dev] [PATCH v22 4/5] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-09-16 3:41 ` [dpdk-dev] [PATCH v22 5/5] app/test: add dmadev API test Chengwen Feng
2021-09-24 10:53 ` [dpdk-dev] [PATCH v23 0/6] support dmadev Chengwen Feng
2021-09-24 10:53 ` [dpdk-dev] [PATCH v23 1/6] dmadev: introduce DMA device library Chengwen Feng
2021-10-04 21:12 ` Radha Mohan
2021-10-05 8:24 ` Kevin Laatz
2021-10-05 16:39 ` Radha Mohan
2021-10-08 1:52 ` fengchengwen
2021-10-06 10:26 ` Thomas Monjalon
2021-10-08 7:13 ` fengchengwen
2021-10-08 10:09 ` Thomas Monjalon
2021-09-24 10:53 ` [dpdk-dev] [PATCH v23 2/6] dmadev: add control plane function support Chengwen Feng
2021-10-05 10:16 ` Matan Azrad
2021-10-08 3:28 ` fengchengwen
2021-10-06 10:46 ` Thomas Monjalon
2021-10-08 7:55 ` fengchengwen
2021-10-08 10:18 ` Thomas Monjalon
2021-09-24 10:53 ` [dpdk-dev] [PATCH v23 3/6] dmadev: add data " Chengwen Feng
2021-09-24 10:53 ` [dpdk-dev] [PATCH v23 4/6] dmadev: add multi-process support Chengwen Feng
2021-09-24 10:53 ` [dpdk-dev] [PATCH v23 5/6] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-09-24 10:53 ` [dpdk-dev] [PATCH v23 6/6] app/test: add dmadev API test Chengwen Feng
2021-10-09 9:33 ` [dpdk-dev] [PATCH v24 0/6] support dmadev Chengwen Feng
2021-10-09 9:33 ` [dpdk-dev] [PATCH v24 1/6] dmadev: introduce DMA device library Chengwen Feng
2021-10-09 9:33 ` [dpdk-dev] [PATCH v24 2/6] dmadev: add control plane API support Chengwen Feng
2021-10-09 9:33 ` [dpdk-dev] [PATCH v24 3/6] dmadev: add data " Chengwen Feng
2021-10-09 10:03 ` fengchengwen
2021-10-11 10:40 ` Bruce Richardson
2021-10-11 12:31 ` fengchengwen
2021-10-09 9:33 ` [dpdk-dev] [PATCH v24 4/6] dmadev: add multi-process support Chengwen Feng
2021-10-09 9:33 ` [dpdk-dev] [PATCH v24 5/6] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-10-09 9:33 ` [dpdk-dev] [PATCH v24 6/6] app/test: add dmadev API test Chengwen Feng
2021-10-11 7:33 ` [dpdk-dev] [PATCH v25 0/6] support dmadev Chengwen Feng
2021-10-11 7:33 ` [dpdk-dev] [PATCH v25 1/6] dmadev: introduce DMA device library Chengwen Feng
2021-10-12 19:09 ` Thomas Monjalon
2021-10-13 0:21 ` fengchengwen
2021-10-13 7:41 ` Thomas Monjalon
2021-10-15 8:29 ` Thomas Monjalon
2021-10-15 9:59 ` fengchengwen
2021-10-15 13:46 ` Thomas Monjalon
2021-10-11 7:33 ` [dpdk-dev] [PATCH v25 2/6] dmadev: add control plane API support Chengwen Feng
2021-10-11 15:44 ` Bruce Richardson
2021-10-12 3:57 ` fengchengwen
2021-10-12 18:57 ` Thomas Monjalon
2021-10-11 7:33 ` [dpdk-dev] [PATCH v25 3/6] dmadev: add data " Chengwen Feng
2021-10-11 7:33 ` [dpdk-dev] [PATCH v25 4/6] dmadev: add multi-process support Chengwen Feng
2021-10-11 7:33 ` [dpdk-dev] [PATCH v25 5/6] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-10-11 7:33 ` [dpdk-dev] [PATCH v25 6/6] app/test: add dmadev API test Chengwen Feng
2021-10-13 12:24 ` [dpdk-dev] [PATCH v26 0/6] support dmadev Chengwen Feng
2021-10-13 12:24 ` [dpdk-dev] [PATCH v26 1/6] dmadev: introduce DMA device library Chengwen Feng
2021-10-13 12:24 ` [dpdk-dev] [PATCH v26 2/6] dmadev: add control plane API support Chengwen Feng
2021-10-13 12:24 ` [dpdk-dev] [PATCH v26 3/6] dmadev: add data " Chengwen Feng
2021-10-13 12:24 ` [dpdk-dev] [PATCH v26 4/6] dmadev: add multi-process support Chengwen Feng
2021-10-13 12:24 ` [dpdk-dev] [PATCH v26 5/6] dma/skeleton: introduce skeleton dmadev driver Chengwen Feng
2021-10-13 12:25 ` [dpdk-dev] [PATCH v26 6/6] app/test: add dmadev API test Chengwen Feng
2021-10-17 19:17 ` [dpdk-dev] [PATCH v26 0/6] support dmadev Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALBAE1MOaCv_RPr-JxHBwQibbecYeOyg2_RKPpMySN=UJx=XpA@mail.gmail.com' \
--to=jerinjacobk@gmail.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=konstantin.ananyev@intel.com \
--cc=liangma@liangbit.com \
--cc=maxime.coquelin@redhat.com \
--cc=mb@smartsharesystems.com \
--cc=nipun.gupta@nxp.com \
--cc=pkapoor@marvell.com \
--cc=radhac@marvell.com \
--cc=sburla@marvell.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).