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

[Thomas Monjalon <thomas@monjalon.net>]

25/10/2021 22:29, 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 :)