26/10/2021 14:38, 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).
David tried to print once per queue. I don't know whether it can work. David?
