[dpdk-dev] [PATCH 1/2] ethdev: fix log level of Tx and Rx dummy functions
Bing Zhao
bingz at nvidia.com
Sat Oct 23 14:45:04 CEST 2021
Hi Ananyev,
> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Sent: Saturday, October 23, 2021 7:47 PM
> To: NBU-Contact-Thomas Monjalon <thomas at monjalon.net>; Bing Zhao
> <bingz at nvidia.com>
> Cc: Yigit, Ferruh <ferruh.yigit at intel.com>;
> andrew.rybchenko at oktetlabs.ru; dev at dpdk.org
> Subject: RE: [PATCH 1/2] ethdev: fix log level of Tx and Rx dummy
> functions
>
> External email: Use caution opening links or attachments
>
>
> > -----Original Message-----
> > From: Thomas Monjalon <thomas at monjalon.net>
> > Sent: Saturday, October 23, 2021 9:33 AM
> > To: Bing Zhao <bingz at nvidia.com>
> > Cc: Yigit, Ferruh <ferruh.yigit at intel.com>;
> > andrew.rybchenko at oktetlabs.ru; dev at dpdk.org; Ananyev, Konstantin
> > <konstantin.ananyev at intel.com>
> > Subject: Re: [PATCH 1/2] ethdev: fix log level of Tx and Rx dummy
> > functions
> >
> > 22/10/2021 23:14, Bing Zhao:
> > > When stopping a port, the data path Tx and Rx burst functions
> should
> > > be stopped firstly conventionally. Then the dummy functions are
> used
> > > to replace the callback functions provided by the PMD.
> > >
> > > When the application stops a port without or before stopping the
> > > data path handling.
>
> If the application really does that, then it is a severe bug in the
> application, then needs to be fixed ASAP.
I agree, this should be some improper / wrong behavior in the application.
>
> > The dummy functions may be invoked heavily and a lot
> > > of logs in these dummy functions will result in a flood.
> >
> > Why does it happen? We should not use a stopped port.
> > Is it a problem of core synchronization?
> >
> > > Debug level log should be enough instead of the error level.
> >
> >
>
> Dummy function is supposed to be set only when device is not able to
> do RX/TX properly (not attached, or attached but not configured, or
> attached and configured, but not started).
> Obviously if app calls rx/tx_burst for such port it is a major issue,
> that should be flagged immediately.
> So I believe having ERR level here makes a perfect sense here.
I do not insist on this. Some notification to the application may be needed. While to my understanding, the log flood should be prevented, or the logs may slow down the application, the IO, and would also have impact on other logs and some information may get lost (but that is the users' decision).
Since the rx/tx burst are usually in the data path and invoked heavily, if the log is needed, how about print it only once? WDYT?
BR. Bing
More information about the dev
mailing list