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

[Ananyev, Konstantin]

> > > > > > > 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.
> >
> > It is still not clear to me why it is going to be a recurring one?
> > Ok, right now we have some test-cases that are misbehaving unintentionally.
> > So we need to fix them.
> > I admit that it might be a pain, but it still looks like a one time job to me.
> > With new test-cases we should be able to catch such misbehaving at patch
> > submission stage (by checking then logs).
> > I guess there might be some test-cases that misbehave intentionally -
> > some negative test-cases for error-condition checking etc.
> > But for them error message in the log and error return value seems like a
> > right thing, no? Again I expect such test-cases do erroneous rx/tx_burst
> > just few times (not dozens or hundreds) so they shouldn't pollute log too much.
> > So, what I am missing here?
> 
> You don't miss anything, but as you said above, we are going to catch
> some issues at patch submission stage.
> And we want this stage to be easy to catch.
> Having megabytes of log does not help to check in the CI.
> 
> > > One thing that could be done is compiling with asserts in CI, and let
> > > default build not have those asserts.
> >
> > Agree, log+assert seems like a good alternative to panic() for me.
> >
> > > Otherwise, logging once should be enough (I have a patch for this latter idea).
> >
> > I understand the intention, but I am a bit sceptical about that one:
> > it is quite often people don’t pay much attention to single log message.
> 
> Not a good argument in my opinion.
> One error == one log.
> We are not going to flood all error logs to make sure devs pay attention :)

Well, that error could come from different sources (rx/tx, different ports, etc.).
But yes, healthy CI is important.
So if suppressing subsequent messages will help it anyhow, I wouldn't object.
Few thoughts though:
we probably need to make it more informative (and scary :)) then now:
bump log-level, print current lcore id and dump current call-stack.
Another thought - might be worth to make it logging once per lcore
(instead of global logging once).