25/10/2021 14:55, Ananyev, Konstantin: > > > > > 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. > > > > If correctly behaving app should not do this, why not put an assert() > > or a rte_panic? > > This way, the users will definitely catch it. > > That was my first intention, though generic DPDK policy is > to avoid panics inside library functions. > But if everyone think it would be ok here, then I am fine with it too.
I would prefer not having panic/assert in the lib. > > > There is a concern about getting efficient log report, > > > especially when looking at CI issues. > > > > +1. > > The current solution with logs is a real pain. > > Are you guys talking about problems with > app/test/sample_packet_forward.* David reported? > Or some extra problems arise? The problem will arise each time an app is misbehaving. That's going to be a recurring problem in the CI.
