Re: [dpdk-dev] [PATCH 1/2] ethdev: fix log level of Tx and Rx dummy functions

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> > > > 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?
> 

Correctly behaving app should never call these stub functions and should never see these messages.
If your app ended up inside this function, then there something really wrong is going on,
that can cause app crash, silent memory corruption, NIC HW hang, or many other nasty things.
The aim of this stubs mechanism:
1) minimize (but not completely avoid) risk of such damage to happen in case of
    programming error within user app.
2) flag to the user that something very wrong is going on within his app.
In such situation, possible slowdown of misbehaving program is out of my concern.