From: fengchengwen <fengchengwen@huawei.com>
To: Bruce Richardson <bruce.richardson@intel.com>,
Jerin Jacob <jerinjacobk@gmail.com>
Cc: "Thomas Monjalon" <thomas@monjalon.net>,
"Ferruh Yigit" <ferruh.yigit@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: Thu, 8 Jul 2021 11:11:51 +0800 [thread overview]
Message-ID: <9b063d9f-5b52-8e1b-e12a-f24f4ea3b122@huawei.com> (raw)
In-Reply-To: <YOWJlXvHqQOsMECo@bricha3-MOBL.ger.corp.intel.com>
On 2021/7/7 19:01, Bruce Richardson wrote:
> On Wed, Jul 07, 2021 at 04:04:16PM +0530, Jerin Jacob wrote:
>> On Wed, Jul 7, 2021 at 2:05 PM Bruce Richardson
>> <bruce.richardson@intel.com> wrote:
>>>
>>> On Wed, Jul 07, 2021 at 01:38:58PM +0530, Jerin Jacob wrote:
>>>> On Mon, Jul 5, 2021 at 10:46 PM Bruce Richardson
>>>> <bruce.richardson@intel.com> wrote:
>>>>>
>>>>> On Mon, Jul 05, 2021 at 09:25:34PM +0530, Jerin Jacob wrote:
>>>>>>
>>>>>> On Mon, Jul 5, 2021 at 4:22 PM Bruce Richardson
>>>>>> <bruce.richardson@intel.com> wrote:
>>>>>>>
>>>>>>> On Sun, Jul 04, 2021 at 03:00:30PM +0530, Jerin Jacob wrote:
>>>>>>>> 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.
>>>>> <snip>
>>>>>>>
>>>>>>> +1 and the terminology with regards to queues and channels. With our ioat
>>>>>>> hardware, each HW queue was called a channel for instance.
>>>>>>
>>>>>> Looks like <dmadev> <> <channel> can cover all the use cases, if the
>>>>>> HW has more than
>>>>>> 1 queues it can be exposed as separate dmadev dev.
>>>>>>
>>>>>
>>>>> Fine for me.
>>>>>
>>>>> However, just to confirm that Morten's suggestion of using a
>>>>> (device-specific void *) channel pointer rather than dev_id + channel_id
>>>>> pair of parameters won't work for you? You can't store a pointer or dev
>>>>> index in the channel struct in the driver?
>>>>
>>>> Yes. That will work. To confirm, the suggestion is to use, void *
>>>> object instead of channel_id,
>>>> That will avoid one more indirection.(index -> pointer)
>>>>
>>>
>>> The proposal was to use it in place of "dev_id + channel_id", i.e.
>>>
>>> copy(dev_id, ch_id, src, dst, len, flags) --> copy(ch_ptr, src, dst, len, flags)
>>>
>>> Where the channel pointer implicitly indicates the device too. However, I
>>> realise now that this would be something completely transparent to the
>>> driver as it would all have to be implemented in the dmadev level, and
>>> lead to lots of duplication of function pointers, etc. Therefore, let's
>>> just go with original scheme. :-(
>>
>> Yes. Just go with the original scheme.
>>
> +1
>
>>>
>>>>
>>>>>
>>>>>>
>>>
>>> <snip>
>>>
>>>>>> Got it. In order to save space if first CL size for fastpath(Saving 8B
>>>>>> for the pointer) and to avoid
>>>>>> function overhead, Can we use one bit of flags of op function to
>>>>>> enable the fence?
>>>>>>
>>>>>
>>>>> The original ioat implementation did exactly that. However, I then
>>>>> discovered that because a fence logically belongs between two operations,
>>>>> does the fence flag on an operation mean "don't do any jobs after this
>>>>> until this job has completed" or does it mean "don't start this job until
>>>>> all previous jobs have completed". [Or theoretically does it mean both :-)]
>>>>> Naturally, some hardware does it the former way (i.e. fence flag goes on
>>>>> last op before fence), while other hardware the latter way (i.e. fence flag
>>>>> goes on first op after the fence). Therefore, since fencing is about
>>>>> ordering *between* two (sets of) jobs, I decided that it should do exactly
>>>>> that and go between two jobs, so there is no ambiguity!
>>>>>
>>>>> However, I'm happy enough to switch to having a fence flag, but I think if
>>>>> we do that, it should be put in the "first job after fence" case, because
>>>>> it is always easier to modify a previously written job if we need to, than
>>>>> to save the flag for a future one.
>>>>>
>>>>> Alternatively, if we keep the fence as a separate function, I'm happy
>>>>> enough for it not to be on the same cacheline as the "hot" operations,
>>>>> since fencing will always introduce a small penalty anyway.
>>>>
>>>> Ack.
>>>> You may consider two flags, FENCE_THEN_JOB and JOB_THEN_FENCE( If
>>>> there any use case for this or it makes sense for your HW)
>>>>
>>>>
>>>> For us, Fence is NOP for us as we have an implicit fence between each
>>>> HW job descriptor.
>>>>
>>>
>>> I actually still think that having a separate fence function in the "ops"
>>> section is the best approach here. It's unabiguous as to whether it's
>>> fence-before or fence-after, and if we have it in the ops, it doesn't use a
>>> "fast-path" slot.
>>>
>>> However, if we *really* want to use a flag instead, I don't see the value
>>> in having two flags, it will be really confusing. Instead, if we do go
>>> with a flag, I think "RTE_DMA_PRE_FENCE" should be the name, indicating
>>> that the fence occurs before the job in question.
>>
>> IMO, We need to use flags and the name can be RTE_DMA_PRE_FENCE
>> due to overhead of the driver implementation where the fence request
>> can be NOP and
>> to save the first cache line occupancy.
>>
>>>
>>>>
>>>>>
>>>>>>>
>>>>>>>>
>>>>> <snip>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>
>>>>>>> In our benchmarks it's just faster. When we tested it, the overhead of the
>>>>>>> function calls was noticably less than the cost of building up the
>>>>>>> parameter array(s) for passing the jobs in as a burst. [We don't see this
>>>>>>> cost with things like NIC I/O since DPDK tends to already have the mbuf
>>>>>>> fully populated before the TX call anyway.]
>>>>>>
>>>>>> OK. I agree with stack population.
>>>>>>
>>>>>> My question was more on doing implicit doorbell update enq. Is doorbell write
>>>>>> costly in other HW compare to a function call? In our HW, it is just write of
>>>>>> the number of instructions written in a register.
>>>>>>
>>>>>> Also, we need to again access the internal PMD memory structure to find
>>>>>> where to write etc if it is a separate function.
>>>>>>
>>>>>
>>>>> The cost varies depending on a number of factors - even writing to a single
>>>>> HW register can be very slow if that register is mapped as device
>>>>> (uncacheable) memory, since (AFAIK) it will act as a full fence and wait
>>>>
>>>> I don't know, At least in our case, writes are write-back. so core does not need
>>>> to wait.(If there is no read operation).
>>>>
>>>>> for the write to go all the way to hardware. For more modern HW, the cost
>>>>> can be lighter. However, any cost of HW writes is going to be the same
>>>>> whether its a separate function call or not.
>>>>>
>>>>> However, the main thing about the doorbell update is that it's a
>>>>> once-per-burst thing, rather than a once-per-job. Therefore, even if you
>>>>> have to re-read the struct memory (which is likely still somewhere in your
>>>>> cores' cache), any extra small cost of doing so is to be amortized over the
>>>>> cost of a whole burst of copies.
>>>>
>>>> Linux kernel has xmit_more flag in skb to address similar thing.
>>>> i.e enq job flag can have one more bit field to say update ring bell or not?
>>>> Rather having yet another function overhead.IMO, it is the best of both worlds.
>>>>
>>>
>>> It's just more conditionals and branches all through the code. Inside the
>>> user application, the user has to check whether to set the flag or not (or
>>> special-case the last transaction outside the loop), and within the driver,
>>> there has to be a branch whether or not to call the doorbell function. The
>>> code on both sides is far simpler and more readable if the doorbell
>>> function is exactly that - a separate function.
>>
>> I disagree. The reason is:
>>
>> We will have two classes of applications
>>
>> a) do dma copy request as and when it has data(I think, this is the
>> prime use case), for those,
>> I think, it is considerable overhead to have two function invocation
>> per transfer i.e
>> rte_dma_copy() and rte_dma_perform()
>>
>> b) do dma copy when the data is reached to a logical state, like copy
>> IP frame from Ethernet packets or so,
>> In that case, the application will have a LOGIC to detect when to
>> perform it so on the end of
>> that rte_dma_copy() flag can be updated to fire the doorbell.
>>
>> IMO, We are comparing against a branch(flag is already in register) vs
>> a set of instructions for
>> 1) function pointer overhead
>> 2) Need to use the channel context again back in another function.
>>
>> IMO, a single branch is most optimal from performance PoV.
>>
> Ok, let's try it and see how it goes.
Test result show:
1) For Kunpeng platform (ARMv8) could benefit very little with doorbell in flags
2) For Xeon E5-2690 v2 (X86) could benefit with separate function
3) Both platform could benefit with doorbell in flags if burst < 5
There is a performance gain in small bursts (<5). Given the extensive use of bursts
in DPDK applications and users are accustomed to the concept, I do not recommend
using the 'doorbell' in flags.
And also user may confuse about the doorbell operations.
Kunpeng platform test result:
[root@SZ tmp]# ./a1 1
burst = 1
perform_after_multiple_enqueue: burst:1 cost:0s.554422us
doorbell_for_every_enqueue: burst:1 cost:0s.450927us
last_enqueue_issue_doorbell: burst:1 cost:0s.450479us
[root@SZ tmp]#
[root@SZ tmp]# ./a1 2
burst = 2
perform_after_multiple_enqueue: burst:2 cost:0s.900884us
doorbell_for_every_enqueue: burst:2 cost:0s.866732us
last_enqueue_issue_doorbell: burst:2 cost:0s.732469us
[root@SZ tmp]# ./a1 5
burst = 5
perform_after_multiple_enqueue: burst:5 cost:1s.732410us
doorbell_for_every_enqueue: burst:5 cost:2s.115479us
last_enqueue_issue_doorbell: burst:5 cost:1s.759349us
[root@SZ tmp]# ./a1 10
burst = 10
perform_after_multiple_enqueue: burst:10 cost:3s.490716us
doorbell_for_every_enqueue: burst:10 cost:4s.194691us
last_enqueue_issue_doorbell: burst:10 cost:3s.331825us
[root@SZ tmp]# ./a1 30
burst = 30
perform_after_multiple_enqueue: burst:30 cost:9s.61761us
doorbell_for_every_enqueue: burst:30 cost:12s.517082us
last_enqueue_issue_doorbell: burst:30 cost:9s.614802us
X86 platform test result:
fengchengwen@SZ:~/tmp$ ./a1 1
burst = 1
perform_after_multiple_enqueue: burst:1 cost:0s.406331us
doorbell_for_every_enqueue: burst:1 cost:0s.331109us
last_enqueue_issue_doorbell: burst:1 cost:0s.381782us
fengchengwen@SZ:~/tmp$ ./a1 2
burst = 2
perform_after_multiple_enqueue: burst:2 cost:0s.569024us
doorbell_for_every_enqueue: burst:2 cost:0s.643449us
last_enqueue_issue_doorbell: burst:2 cost:0s.486639us
fengchengwen@SZ:~/tmp$ ./a1 5
burst = 5
perform_after_multiple_enqueue: burst:5 cost:1s.166384us
doorbell_for_every_enqueue: burst:5 cost:1s.602369us
last_enqueue_issue_doorbell: burst:5 cost:1s.209392us
fengchengwen@SZ:~/tmp$ ./a1 10
burst = 10
perform_after_multiple_enqueue: burst:10 cost:2s.229901us
doorbell_for_every_enqueue: burst:10 cost:3s.754802us
last_enqueue_issue_doorbell: burst:10 cost:2s.328705us
fengchengwen@SZ:~/tmp$
fengchengwen@SZ:~/tmp$ ./a1 30
burst = 30
perform_after_multiple_enqueue: burst:30 cost:6s.132817us
doorbell_for_every_enqueue: burst:30 cost:9s.944619us
last_enqueue_issue_doorbell: burst:30 cost:7s.73551us
test-code:
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <time.h>
#include <sys/time.h>
struct dmadev;
unsigned int dev_reg[10240];
volatile unsigned int *ring;
volatile unsigned int *doorbell;
void init_global(void)
{
ring = &dev_reg[100];
doorbell = &dev_reg[10000];
}
#define rte_wmb() asm volatile("dmb oshst" : : : "memory")
//#define rte_wmb() asm volatile ("" : : : "memory")
typedef int (*enqueue_t)(struct dmadev *dev, int vchan, void *src, void *dst, int len, int flags);
typedef void (*perform_t)(struct dmadev *dev, int vchan);
struct dmadev {
enqueue_t enqueue;
perform_t perform;
char rsv[512];
};
int hisi_dma_enqueue(struct dmadev *dev, int vchan, void *src, void *dst, int len, int flags)
{
*ring = 1;
}
int hisi_dma_enqueue_doorbell(struct dmadev *dev, int vchan, void *src, void *dst, int len, int flags)
{
*ring = 1;
if (flags == 1) {
rte_wmb();
*doorbell = 1;
}
}
void hisi_dma_perform(struct dmadev *dev, int vchan)
{
rte_wmb();
*doorbell = 1;
}
struct dmadev devlist[64];
void init_devlist(bool enq_doorbell)
{
int i;
for (i = 0; i < 64; i++) {
devlist[i].enqueue = enq_doorbell ? hisi_dma_enqueue_doorbell : hisi_dma_enqueue;
devlist[i].perform = hisi_dma_perform;
}
}
static inline int dma_enqueue(int dev_id, int vchan, void *src, void *dst, int len, int flags)
{
struct dmadev *dev = &devlist[dev_id];
return dev->enqueue(dev, vchan, src, dst, len, flags);
}
static inline void dma_perform(int dev_id, int vchan)
{
struct dmadev *dev = &devlist[dev_id];
return dev->perform(dev, vchan);
}
#define MAX_LOOPS 90000000
void test_for_perform_after_multiple_enqueue(int burst)
{
struct timeval start, end, delta;
unsigned int i, j;
init_devlist(false);
gettimeofday(&start, NULL);
for (i = 0; i < MAX_LOOPS; i++) {
for (j = 0; j < burst; j++)
(void)dma_enqueue(10, 0, NULL, NULL, 0, 0);
dma_perform(10, 0);
}
gettimeofday(&end, NULL);
timersub(&end, &start, &delta);
printf("perform_after_multiple_enqueue: burst:%d cost:%us.%uus \n", burst, delta.tv_sec, delta.tv_usec);
}
void test_for_doorbell_for_every_enqueue(int burst)
{
struct timeval start, end, delta;
unsigned int i, j;
init_devlist(true);
gettimeofday(&start, NULL);
for (i = 0; i < MAX_LOOPS; i++) {
for (j = 0; j < burst; j++)
(void)dma_enqueue(10, 0, NULL, NULL, 0, 1);
}
gettimeofday(&end, NULL);
timersub(&end, &start, &delta);
printf("doorbell_for_every_enqueue: burst:%d cost:%us.%uus \n", burst, delta.tv_sec, delta.tv_usec);
}
void test_for_last_enqueue_issue_doorbell(int burst)
{
struct timeval start, end, delta;
unsigned int i, j;
init_devlist(true);
gettimeofday(&start, NULL);
for (i = 0; i < MAX_LOOPS; i++) {
for (j = 0; j < burst - 1; j++)
(void)dma_enqueue(10, 0, NULL, NULL, 0, 0);
dma_enqueue(10, 0, NULL, NULL, 0, 1);
}
gettimeofday(&end, NULL);
timersub(&end, &start, &delta);
printf("last_enqueue_issue_doorbell: burst:%d cost:%us.%uus \n", burst, delta.tv_sec, delta.tv_usec);
}
void main(int argc, char *argv[])
{
if (argc < 2) {
printf("please input burst parameter!\n");
return;
}
init_global();
int burst = atol(argv[1]);
printf("burst = %d \n", burst);
test_for_perform_after_multiple_enqueue(burst);
test_for_doorbell_for_every_enqueue(burst);
test_for_last_enqueue_issue_doorbell(burst);
}
>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>> <snip>
>>>>>>>>> + +/** + * @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. */ };
>>>>>>>>
>>>>>>>
>>>>>>> I think we need a multi-return value API here, as we may add
>>>>>>> operations in future which have non-error status values to return.
>>>>>>> The obvious case is DMA engines which support "compare" operations.
>>>>>>> In that case a successful compare (as in there were no DMA or HW
>>>>>>> errors) can return "equal" or "not-equal" as statuses. For general
>>>>>>> "copy" operations, the faster completion op can be used to just
>>>>>>> return successful values (and only call this status version on
>>>>>>> error), while apps using those compare ops or a mixture of copy and
>>>>>>> compare ops, would always use the slower one that returns status
>>>>>>> values for each and every op..
>>>>>>>
>>>>>>> The ioat APIs used 32-bit integer values for this status array so
>>>>>>> as to allow e.g. 16-bits for error code and 16-bits for future
>>>>>>> status values. For most operations there should be a fairly small
>>>>>>> set of things that can go wrong, i.e. bad source address, bad
>>>>>>> destination address or invalid length. Within that we may have a
>>>>>>> couple of specifics for why an address is bad, but even so I don't
>>>>>>> think we need to start having multiple bit combinations.
>>>>>>
>>>>>> OK. What is the purpose of errors status? Is it for application
>>>>>> printing it or Does the application need to take any action based on
>>>>>> specific error requests?
>>>>>
>>>>> It's largely for information purposes, but in the case of SVA/SVM
>>>>> errors could occur due to the memory not being pinned, i.e. a page
>>>>> fault, in some cases. If that happens, then it's up the app to either
>>>>> touch the memory and retry the copy, or to do a SW memcpy as a
>>>>> fallback.
>>>>>
>>>>> In other error cases, I think it's good to tell the application if it's
>>>>> passing around bad data, or data that is beyond the scope of hardware,
>>>>> e.g. a copy that is beyond what can be done in a single transaction
>>>>> for a HW instance. Given that there are always things that can go
>>>>> wrong, I think we need some error reporting mechanism.
>>>>>
>>>>>> If the former is scope, then we need to define the standard enum
>>>>>> value for the error right? ie. uint32_t *status needs to change to
>>>>>> enum rte_dma_error or so.
>>>>>>
>>>>> Sure. Perhaps an error/status structure either is an option, where we
>>>>> explicitly call out error info from status info.
>>>>
>>>> Agree. Better to have a structure with filed like,
>>>>
>>>> 1) enum rte_dma_error_type 2) memory to store, informative message on
>>>> fine aspects of error. LIke address caused issue etc.(Which will be
>>>> driver-specific information).
>>>>
>>> The only issue I have with that is that once we have driver specific
>>> information it is of little use to the application, since it can't know
>>> anything about it excepy maybe log it. I'd much rather have a set of error
>>> codes telling user that "source address is wrong", "dest address is wrong",
>>> and a generic "an address is wrong" in case driver/HW cannot distinguish
>>> source of error. Can we see how far we get with just error codes before we
>>> start into passing string messages around and all the memory management
>>> headaches that implies.
>>
>> Works for me. It should be "enum rte_dma_error_type" then, which has a standard
>> error type. Which is missing in the spec now.
>>
> +1
> .
>
next prev parent reply other threads:[~2021-07-08 3:11 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
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 [this message]
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=9b063d9f-5b52-8e1b-e12a-f24f4ea3b122@huawei.com \
--to=fengchengwen@huawei.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.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).