[dpdk-dev] [PATCH v2 10/29] net/ena/base: add error logs when preparing Tx

[Michał Krawczyk]

czw., 2 kwi 2020 o 14:53 Ferruh Yigit <ferruh.yigit at intel.com> napisał(a):
>
> On 4/1/2020 3:21 PM, Michal Krawczyk wrote:
> > To make the debugging easier, the error logs were added in the Tx path.
> >
> > Signed-off-by: Michal Krawczyk <mk at semihalf.com>
> > Reviewed-by: Igor Chauskin <igorch at amazon.com>
> > Reviewed-by: Guy Tzalik <gtzalik at amazon.com>
> > ---
> >  drivers/net/ena/base/ena_eth_com.c | 24 +++++++++++++++++++-----
> >  1 file changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ena/base/ena_eth_com.c b/drivers/net/ena/base/ena_eth_com.c
> > index aabc294fb7..747450fec5 100644
> > --- a/drivers/net/ena/base/ena_eth_com.c
> > +++ b/drivers/net/ena/base/ena_eth_com.c
> > @@ -148,8 +148,10 @@ static int ena_com_close_bounce_buffer(struct ena_com_io_sq *io_sq)
> >       if (pkt_ctrl->idx) {
> >               rc = ena_com_write_bounce_buffer_to_dev(io_sq,
> >                                                       pkt_ctrl->curr_bounce_buf);
> > -             if (unlikely(rc))
> > +             if (unlikely(rc)) {
> > +                     ena_trc_err("failed to write bounce buffer to device\n");
>
> Is 'ena_trc_err()' for datapath?
>

ena_trc_err() is being used in both control and datapath.

> DPDK has two types of logs,
> - for control path, dynamic logging, whose logging level can be dynamically changed
> - for data path, a compile time controlled logging, this is to prevent
> performance loss in data path. For ena these flags are
> CONFIG_RTE_LIBRTE_ENA_DEBUG_RX=n
> CONFIG_RTE_LIBRTE_ENA_DEBUG_TX=n
> CONFIG_RTE_LIBRTE_ENA_DEBUG_TX_FREE=n
>
>
> I can see ena also has 'RTE_LIBRTE_ENA_COM_DEBUG' compile to flag, which
> controls above 'ena_trc_err' variants. If this is control path, what do you
> think removing the compile time flag and convert these 'COM' logs to dynamic
> logging?

I agree with you that it would be great if we would use dynamic
logging for control path - I must talk with engineers responsible for
ena_com to raise that issue and, hopefully, it'll be possible to
adjust that in the future.

I suggest to postpone that kind of change for the next release, as
making ena_com changes is a bit time consuming.