On Sun, Apr 26, 2020 at 1:42 AM Thomas Monjalon <tho...@monjalon.net> wrote: > > 06/02/2020 15:36, Jerin Jacob: > > On Thu, Feb 6, 2020 at 7:44 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > > 21/01/2020 09:00, jer...@marvell.com: > > > > From: Jerin Jacob <jer...@marvell.com> > > > > > > > > Some machines may have a lot of PCI devices, logs from PCI probe > > > > creates a lot of clutter on boot-up, typically one needs > > > > to scroll the screen to find other issues in boot-up. > > > > > > > > This patch changes the loglevel of PCI probes to `debug` > > > > to reduce the clutter on default boot-up logs > > > > > > I think the PCI probe informations are... informational. > > > Maybe you are just not interested in info logs. > > > If this is the case, I suggest to change the log level at runtime. > > > > I am wondering, what would be the right balance, Following is DPDK > > startup output from octeontx2[1] > > It creates a lot of clutter in the "default" boot up. Why not enable > > below prints using log level at runtime? > > I believe it comes as a debug category, i.e information required to > > debug if something is not working, > > dpdk bind script already lists what is bound to DPDK. > > > > Suggestion to remove clutter? > > I suggest using dynamic log level in the PCI driver. > Unfortunately a lot of old DPDK code is still using the old log macros. > Some cleanup work is needed here.
Sent an alternative fix to skip probing the devices with RTE_KDRV_NONE. I think that is the source of the problem. http://patches.dpdk.org/patch/69351/ > >
