24/10/2021 13:48, Ananyev, Konstantin: > > > > > > 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.
There is a concern about getting efficient log report, especially when looking at CI issues.
