[v2,3/3] baseband/acc: add internal logging
Checks
Commit Message
Adds internal buffer for more flexible logging.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
drivers/baseband/acc/acc_common.h | 22 +++++++++++++++++++---
drivers/baseband/acc/rte_vrb_pmd.c | 18 +++++++++++++++++-
2 files changed, 36 insertions(+), 4 deletions(-)
Comments
On Thu, 23 Jan 2025 14:55:19 -0800
Nicolas Chautru <nicolas.chautru@intel.com> wrote:
> Adds internal buffer for more flexible logging.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
Inventing another device specific error log seems like a short sighted concept.
Why doesn't existing DPDK logging work well enough?
Hi Stephen,
The commit message may be misleading, the logging interface doesn't change here. Note also that I reuse existing trace point framework for some of the error logging when relevant (see previous commit).
Here the scope for that buffer is more limited, not a new logging method really (the commit message is misleading).
The queue_ops_dump() already provides api to dump device specific information related to queue into file (logging in real time is not an option) based on information already in PMD memory.
This new buffer is purely there to add storage for the string out of rte_bbdev_ops_param_string() for failed operation on that queue, so that extend that capture as this info is not stored by PMD.
The name of the buffer could be renamed probably, or I could store copy of the actual operation instead of the string in case that makes a difference for you.
I guess it would possible to move this to trace point but I thought it would be quite convoluted. That information would fits nicely in the queue dump capture, and this would require adding trace point for each operation type (I don't believe it can manage arbitrary string) and would be a bit of an unconventional use of trace point.
Any thought?
Thanks
Nic
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, January 23, 2025 3:24 PM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>
> Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
> hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
> Subject: Re: [PATCH v2 3/3] baseband/acc: add internal logging
>
> On Thu, 23 Jan 2025 14:55:19 -0800
> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
>
> > Adds internal buffer for more flexible logging.
> >
> > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
>
> Inventing another device specific error log seems like a short sighted
> concept.
> Why doesn't existing DPDK logging work well enough?
On Fri, 24 Jan 2025 17:52:43 +0000
"Chautru, Nicolas" <nicolas.chautru@intel.com> wrote:
> Hi Stephen,
>
> The commit message may be misleading, the logging interface doesn't change here. Note also that I reuse existing trace point framework for some of the error logging when relevant (see previous commit).
> Here the scope for that buffer is more limited, not a new logging method really (the commit message is misleading).
> The queue_ops_dump() already provides api to dump device specific information related to queue into file (logging in real time is not an option) based on information already in PMD memory.
> This new buffer is purely there to add storage for the string out of rte_bbdev_ops_param_string() for failed operation on that queue, so that extend that capture as this info is not stored by PMD.
> The name of the buffer could be renamed probably, or I could store copy of the actual operation instead of the string in case that makes a difference for you.
>
> I guess it would possible to move this to trace point but I thought it would be quite convoluted. That information would fits nicely in the queue dump capture, and this would require adding trace point for each operation type (I don't believe it can manage arbitrary string) and would be a bit of an unconventional use of trace point.
>
> Any thought?
>
> Thanks
> Nic
>
>
> > -----Original Message-----
> > From: Stephen Hemminger <stephen@networkplumber.org>
> > Sent: Thursday, January 23, 2025 3:24 PM
> > To: Chautru, Nicolas <nicolas.chautru@intel.com>
> > Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
> > hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
> > Subject: Re: [PATCH v2 3/3] baseband/acc: add internal logging
> >
> > On Thu, 23 Jan 2025 14:55:19 -0800
> > Nicolas Chautru <nicolas.chautru@intel.com> wrote:
> >
> > > Adds internal buffer for more flexible logging.
> > >
> > > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> >
> > Inventing another device specific error log seems like a short sighted
> > concept.
> > Why doesn't existing DPDK logging work well enough?
>
My feedback is that why can't you just use DEBUG logging for this.
Hi Stephen,
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Friday, January 24, 2025 10:01 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>
> Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
> hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
> Subject: Re: [PATCH v2 3/3] baseband/acc: add internal logging
>
> On Fri, 24 Jan 2025 17:52:43 +0000
> "Chautru, Nicolas" <nicolas.chautru@intel.com> wrote:
>
> > Hi Stephen,
> >
> > The commit message may be misleading, the logging interface doesn't
> change here. Note also that I reuse existing trace point framework for some
> of the error logging when relevant (see previous commit).
> > Here the scope for that buffer is more limited, not a new logging method
> really (the commit message is misleading).
> > The queue_ops_dump() already provides api to dump device specific
> information related to queue into file (logging in real time is not an option)
> based on information already in PMD memory.
> > This new buffer is purely there to add storage for the string out of
> rte_bbdev_ops_param_string() for failed operation on that queue, so that
> extend that capture as this info is not stored by PMD.
> > The name of the buffer could be renamed probably, or I could store copy
> of the actual operation instead of the string in case that makes a difference
> for you.
> >
> > I guess it would possible to move this to trace point but I thought it would
> be quite convoluted. That information would fits nicely in the queue dump
> capture, and this would require adding trace point for each operation type (I
> don't believe it can manage arbitrary string) and would be a bit of an
> unconventional use of trace point.
> >
> > Any thought?
> >
> > Thanks
> > Nic
> >
> >
> > > -----Original Message-----
> > > From: Stephen Hemminger <stephen@networkplumber.org>
> > > Sent: Thursday, January 23, 2025 3:24 PM
> > > To: Chautru, Nicolas <nicolas.chautru@intel.com>
> > > Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
> > > hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
> > > Subject: Re: [PATCH v2 3/3] baseband/acc: add internal logging
> > >
> > > On Thu, 23 Jan 2025 14:55:19 -0800
> > > Nicolas Chautru <nicolas.chautru@intel.com> wrote:
> > >
> > > > Adds internal buffer for more flexible logging.
> > > >
> > > > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > >
> > > Inventing another device specific error log seems like a short
> > > sighted concept.
> > > Why doesn't existing DPDK logging work well enough?
> >
>
> My feedback is that why can't you just use DEBUG logging for this.
In practice this logging cannot be enabled as this impact real time workload. This is disabled by default for deployment as too intrusive, ie. logging some warning causing application to miss the tight real time constraints.
Hence meaningful logging is being done in practice after the fact using trace point (ie. rte_trace_save()) and/or using the bbdev queue_ops_dump() which are both called outside of real time constraints when we can write to file system.
Hi Nicolas,
On 1/24/25 7:00 PM, Stephen Hemminger wrote:
> On Fri, 24 Jan 2025 17:52:43 +0000
> "Chautru, Nicolas" <nicolas.chautru@intel.com> wrote:
>
>> Hi Stephen,
>>
>> The commit message may be misleading, the logging interface doesn't change here. Note also that I reuse existing trace point framework for some of the error logging when relevant (see previous commit).
>> Here the scope for that buffer is more limited, not a new logging method really (the commit message is misleading).
>> The queue_ops_dump() already provides api to dump device specific information related to queue into file (logging in real time is not an option) based on information already in PMD memory.
>> This new buffer is purely there to add storage for the string out of rte_bbdev_ops_param_string() for failed operation on that queue, so that extend that capture as this info is not stored by PMD.
>> The name of the buffer could be renamed probably, or I could store copy of the actual operation instead of the string in case that makes a difference for you.
>>
>> I guess it would possible to move this to trace point but I thought it would be quite convoluted. That information would fits nicely in the queue dump capture, and this would require adding trace point for each operation type (I don't believe it can manage arbitrary string) and would be a bit of an unconventional use of trace point.
>>
>> Any thought?
I think the introduction of trace points in patch 2 is a good addition,
and could be extended further to not just emit a simple string but also
the necessary values to enable debugging (basically what you write in
the buffers).
It would have the advantage of having the different traces to be
synchronized (bbdev and acc ones), and also would have less performance
impact.
>> Thanks
>> Nic
>>
>>
>>> -----Original Message-----
>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>> Sent: Thursday, January 23, 2025 3:24 PM
>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>
>>> Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
>>> hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
>>> Subject: Re: [PATCH v2 3/3] baseband/acc: add internal logging
>>>
>>> On Thu, 23 Jan 2025 14:55:19 -0800
>>> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
>>>
>>>> Adds internal buffer for more flexible logging.
>>>>
>>>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
>>>
>>> Inventing another device specific error log seems like a short sighted
>>> concept.
>>> Why doesn't existing DPDK logging work well enough?
>>
>
> My feedback is that why can't you just use DEBUG logging for this.
Or indeed could use the existing logging mechanism.
>
Thanks,
Maxime
Hi Nicolas,
On 2/7/25 10:52 AM, Maxime Coquelin wrote:
> Hi Nicolas,
>
> On 1/24/25 7:00 PM, Stephen Hemminger wrote:
>> On Fri, 24 Jan 2025 17:52:43 +0000
>> "Chautru, Nicolas" <nicolas.chautru@intel.com> wrote:
>>
>>> Hi Stephen,
>>>
>>> The commit message may be misleading, the logging interface doesn't
>>> change here. Note also that I reuse existing trace point framework
>>> for some of the error logging when relevant (see previous commit).
>>> Here the scope for that buffer is more limited, not a new logging
>>> method really (the commit message is misleading).
>>> The queue_ops_dump() already provides api to dump device specific
>>> information related to queue into file (logging in real time is not
>>> an option) based on information already in PMD memory.
>>> This new buffer is purely there to add storage for the string out of
>>> rte_bbdev_ops_param_string() for failed operation on that queue, so
>>> that extend that capture as this info is not stored by PMD.
>>> The name of the buffer could be renamed probably, or I could store
>>> copy of the actual operation instead of the string in case that makes
>>> a difference for you.
>>>
>>> I guess it would possible to move this to trace point but I thought
>>> it would be quite convoluted. That information would fits nicely in
>>> the queue dump capture, and this would require adding trace point for
>>> each operation type (I don't believe it can manage arbitrary string)
>>> and would be a bit of an unconventional use of trace point.
>>>
>>> Any thought?
>
> I think the introduction of trace points in patch 2 is a good addition,
> and could be extended further to not just emit a simple string but also
> the necessary values to enable debugging (basically what you write in
> the buffers).
>
> It would have the advantage of having the different traces to be
> synchronized (bbdev and acc ones), and also would have less performance
> impact.
What do you think of this proposal?
how do we proceed for v25.03?
Thanks,
Maxime
>>> Thanks
>>> Nic
>>>
>>>
>>>> -----Original Message-----
>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>> Sent: Thursday, January 23, 2025 3:24 PM
>>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>
>>>> Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
>>>> hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
>>>> Subject: Re: [PATCH v2 3/3] baseband/acc: add internal logging
>>>>
>>>> On Thu, 23 Jan 2025 14:55:19 -0800
>>>> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
>>>>> Adds internal buffer for more flexible logging.
>>>>>
>>>>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
>>>>
>>>> Inventing another device specific error log seems like a short sighted
>>>> concept.
>>>> Why doesn't existing DPDK logging work well enough?
>>>
>>
>> My feedback is that why can't you just use DEBUG logging for this.
>
> Or indeed could use the existing logging mechanism.
>
>>
>
> Thanks,
> Maxime
Hi Maxime,
I believe that for 25.03 we can just apply the first 2 commits of the serie.
For the last commit, it will take more time to try your suggestion out, we can do this in subsequent release.
Does that sound okay with you?
Thanks
Nic
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Friday, February 28, 2025 12:52 AM
> To: Stephen Hemminger <stephen@networkplumber.org>; Chautru, Nicolas
> <nicolas.chautru@intel.com>
> Cc: dev@dpdk.org; hemant.agrawal@nxp.com; Vargas, Hernan
> <hernan.vargas@intel.com>
> Subject: Re: [PATCH v2 3/3] baseband/acc: add internal logging
>
> Hi Nicolas,
>
> On 2/7/25 10:52 AM, Maxime Coquelin wrote:
> > Hi Nicolas,
> >
> > On 1/24/25 7:00 PM, Stephen Hemminger wrote:
> >> On Fri, 24 Jan 2025 17:52:43 +0000
> >> "Chautru, Nicolas" <nicolas.chautru@intel.com> wrote:
> >>
> >>> Hi Stephen,
> >>>
> >>> The commit message may be misleading, the logging interface doesn't
> >>> change here. Note also that I reuse existing trace point framework
> >>> for some of the error logging when relevant (see previous commit).
> >>> Here the scope for that buffer is more limited, not a new logging
> >>> method really (the commit message is misleading).
> >>> The queue_ops_dump() already provides api to dump device specific
> >>> information related to queue into file (logging in real time is not
> >>> an option) based on information already in PMD memory.
> >>> This new buffer is purely there to add storage for the string out of
> >>> rte_bbdev_ops_param_string() for failed operation on that queue, so
> >>> that extend that capture as this info is not stored by PMD.
> >>> The name of the buffer could be renamed probably, or I could store
> >>> copy of the actual operation instead of the string in case that
> >>> makes a difference for you.
> >>>
> >>> I guess it would possible to move this to trace point but I thought
> >>> it would be quite convoluted. That information would fits nicely in
> >>> the queue dump capture, and this would require adding trace point
> >>> for each operation type (I don't believe it can manage arbitrary
> >>> string) and would be a bit of an unconventional use of trace point.
> >>>
> >>> Any thought?
> >
> > I think the introduction of trace points in patch 2 is a good
> > addition, and could be extended further to not just emit a simple
> > string but also the necessary values to enable debugging (basically
> > what you write in the buffers).
> >
> > It would have the advantage of having the different traces to be
> > synchronized (bbdev and acc ones), and also would have less
> > performance impact.
>
> What do you think of this proposal?
> how do we proceed for v25.03?
>
> Thanks,
> Maxime
>
> >>> Thanks
> >>> Nic
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Stephen Hemminger <stephen@networkplumber.org>
> >>>> Sent: Thursday, January 23, 2025 3:24 PM
> >>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>
> >>>> Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
> >>>> hemant.agrawal@nxp.com; Vargas, Hernan
> <hernan.vargas@intel.com>
> >>>> Subject: Re: [PATCH v2 3/3] baseband/acc: add internal logging
> >>>>
> >>>> On Thu, 23 Jan 2025 14:55:19 -0800
> >>>> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
> >>>>> Adds internal buffer for more flexible logging.
> >>>>>
> >>>>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> >>>>
> >>>> Inventing another device specific error log seems like a short
> >>>> sighted concept.
> >>>> Why doesn't existing DPDK logging work well enough?
> >>>
> >>
> >> My feedback is that why can't you just use DEBUG logging for this.
> >
> > Or indeed could use the existing logging mechanism.
> >
> >>
> >
> > Thanks,
> > Maxime
Hi Nicolas,
On 2/28/25 6:28 PM, Chautru, Nicolas wrote:
> Hi Maxime,
>
> I believe that for 25.03 we can just apply the first 2 commits of the serie.
>
> For the last commit, it will take more time to try your suggestion out, we can do this in subsequent release.
>
> Does that sound okay with you?
Yes, that sounds good to me.
Thanks,
Maxime
> Thanks
> Nic
>
>> -----Original Message-----
>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Sent: Friday, February 28, 2025 12:52 AM
>> To: Stephen Hemminger <stephen@networkplumber.org>; Chautru, Nicolas
>> <nicolas.chautru@intel.com>
>> Cc: dev@dpdk.org; hemant.agrawal@nxp.com; Vargas, Hernan
>> <hernan.vargas@intel.com>
>> Subject: Re: [PATCH v2 3/3] baseband/acc: add internal logging
>>
>> Hi Nicolas,
>>
>> On 2/7/25 10:52 AM, Maxime Coquelin wrote:
>>> Hi Nicolas,
>>>
>>> On 1/24/25 7:00 PM, Stephen Hemminger wrote:
>>>> On Fri, 24 Jan 2025 17:52:43 +0000
>>>> "Chautru, Nicolas" <nicolas.chautru@intel.com> wrote:
>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> The commit message may be misleading, the logging interface doesn't
>>>>> change here. Note also that I reuse existing trace point framework
>>>>> for some of the error logging when relevant (see previous commit).
>>>>> Here the scope for that buffer is more limited, not a new logging
>>>>> method really (the commit message is misleading).
>>>>> The queue_ops_dump() already provides api to dump device specific
>>>>> information related to queue into file (logging in real time is not
>>>>> an option) based on information already in PMD memory.
>>>>> This new buffer is purely there to add storage for the string out of
>>>>> rte_bbdev_ops_param_string() for failed operation on that queue, so
>>>>> that extend that capture as this info is not stored by PMD.
>>>>> The name of the buffer could be renamed probably, or I could store
>>>>> copy of the actual operation instead of the string in case that
>>>>> makes a difference for you.
>>>>>
>>>>> I guess it would possible to move this to trace point but I thought
>>>>> it would be quite convoluted. That information would fits nicely in
>>>>> the queue dump capture, and this would require adding trace point
>>>>> for each operation type (I don't believe it can manage arbitrary
>>>>> string) and would be a bit of an unconventional use of trace point.
>>>>>
>>>>> Any thought?
>>>
>>> I think the introduction of trace points in patch 2 is a good
>>> addition, and could be extended further to not just emit a simple
>>> string but also the necessary values to enable debugging (basically
>>> what you write in the buffers).
>>>
>>> It would have the advantage of having the different traces to be
>>> synchronized (bbdev and acc ones), and also would have less
>>> performance impact.
>>
>> What do you think of this proposal?
>> how do we proceed for v25.03?
>>
>> Thanks,
>> Maxime
>>
>>>>> Thanks
>>>>> Nic
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>>>> Sent: Thursday, January 23, 2025 3:24 PM
>>>>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>
>>>>>> Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
>>>>>> hemant.agrawal@nxp.com; Vargas, Hernan
>> <hernan.vargas@intel.com>
>>>>>> Subject: Re: [PATCH v2 3/3] baseband/acc: add internal logging
>>>>>>
>>>>>> On Thu, 23 Jan 2025 14:55:19 -0800
>>>>>> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
>>>>>>> Adds internal buffer for more flexible logging.
>>>>>>>
>>>>>>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
>>>>>>
>>>>>> Inventing another device specific error log seems like a short
>>>>>> sighted concept.
>>>>>> Why doesn't existing DPDK logging work well enough?
>>>>>
>>>>
>>>> My feedback is that why can't you just use DEBUG logging for this.
>>>
>>> Or indeed could use the existing logging mechanism.
>>>
>>>>
>>>
>>> Thanks,
>>> Maxime
>
@@ -152,6 +152,8 @@
#define ACC_MAX_FFT_WIN 16
#define ACC_MAX_RING_BUFFER 64
#define VRB2_MAX_Q_PER_OP 256
+#define ACC_MAX_LOGLEN 256
+#define ACC_MAX_BUFFERLEN 256
extern int acc_common_logtype;
#define RTE_LOGTYPE_ACC_COMMON acc_common_logtype
@@ -652,6 +654,9 @@ struct __rte_cache_aligned acc_queue {
rte_iova_t fcw_ring_addr_iova;
int8_t *derm_buffer; /* interim buffer for de-rm in SDK */
struct acc_device *d;
+ char error_bufs[ACC_MAX_BUFFERLEN][ACC_MAX_LOGLEN]; /**< Buffer for error log. */
+ uint16_t error_head; /**< Head - Buffer for error log. */
+ uint16_t error_wrap; /**< Wrap Counter - Buffer for error log. */
};
/* These strings for rte_trace must be limited to RTE_TRACE_EMIT_STRING_LEN_MAX. */
@@ -690,11 +695,21 @@ __rte_format_printf(4, 5)
static inline void
acc_error_log(struct acc_queue *q, void *op, uint8_t acc_error_idx, const char *fmt, ...)
{
- va_list args;
- RTE_SET_USED(op);
+ va_list args, args2;
+ static char str[1024];
+
va_start(args, fmt);
+ va_copy(args2, args);
rte_vlog(RTE_LOG_ERR, acc_common_logtype, fmt, args);
-
+ vsnprintf(q->error_bufs[q->error_head], ACC_MAX_LOGLEN, fmt, args2);
+ q->error_head++;
+ snprintf(q->error_bufs[q->error_head], ACC_MAX_LOGLEN,
+ "%s", rte_bbdev_ops_param_string(op, q->op_type, str, sizeof(str)));
+ q->error_head++;
+ if (q->error_head == ACC_MAX_LOGLEN) {
+ q->error_head = 0;
+ q->error_wrap++;
+ }
if (acc_error_idx > ACC_ERR_MAX)
acc_error_idx = ACC_ERR_MAX;
@@ -702,6 +717,7 @@ acc_error_log(struct acc_queue *q, void *op, uint8_t acc_error_idx, const char *
acc_error_string[acc_error_idx]);
va_end(args);
+ va_end(args2);
}
/* Write to MMIO register address */
@@ -1135,6 +1135,10 @@ vrb_queue_setup(struct rte_bbdev *dev, uint16_t queue_id,
q->mmio_reg_enqueue = RTE_PTR_ADD(d->mmio_base,
d->queue_offset(d->pf_device, q->vf_id, q->qgrp_id, q->aq_id));
+ /** initialize the error buffer. */
+ q->error_head = 0;
+ q->error_wrap = 0;
+
rte_bbdev_log_debug(
"Setup dev%u q%u: qgrp_id=%u, vf_id=%u, aq_id=%u, aq_depth=%u, mmio_reg_enqueue=%p base %p",
dev->data->dev_id, queue_id, q->qgrp_id, q->vf_id,
@@ -1516,7 +1520,7 @@ vrb_queue_ops_dump(struct rte_bbdev *dev, uint16_t queue_id, FILE *f)
{
struct acc_queue *q = dev->data->queues[queue_id].queue_private;
struct rte_bbdev_dec_op *op;
- uint16_t i, int_nb;
+ uint16_t start_err, end_err, i, int_nb;
volatile union acc_info_ring_data *ring_data;
uint16_t info_ring_head = q->d->info_ring_head;
static char str[1024];
@@ -1533,6 +1537,18 @@ vrb_queue_ops_dump(struct rte_bbdev *dev, uint16_t queue_id, FILE *f)
q->aq_enqueued, q->aq_dequeued, q->aq_depth,
acc_ring_avail_enq(q), acc_ring_avail_deq(q));
+ /** Print information captured in the error buffer. */
+ if (q->error_wrap == 0) {
+ start_err = 0;
+ end_err = q->error_head;
+ } else {
+ start_err = q->error_head;
+ end_err = q->error_head + ACC_MAX_BUFFERLEN;
+ }
+ fprintf(f, "Error Buffer - Head %d Wrap %d\n", q->error_head, q->error_wrap);
+ for (i = start_err; i < end_err; ++i)
+ fprintf(f, " %d\t%s", i, q->error_bufs[i % ACC_MAX_BUFFERLEN]);
+
/** Print information captured in the info ring. */
if (q->d->info_ring != NULL) {
fprintf(f, "Info Ring Buffer - Head %d\n", q->d->info_ring_head);