On Mon, Apr 27, 2020 at 1:26 AM Thomas Monjalon <tho...@monjalon.net> wrote: > > 26/04/2020 20:48, Jerin Jacob: > > On Sun, Apr 26, 2020 at 11:37 PM Thomas Monjalon <tho...@monjalon.net> > > wrote: > > > 26/04/2020 19:42, Jerin Jacob: > > > > 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. > > > > > > No, a PCI PMD can work without a known kernel driver. > > > This is the case of mlx4/mlx5. > > > > Yes. it can work with UNKNOWN, But It not with NONE. > > > > > > I think that is the source of the problem. > > > > http://patches.dpdk.org/patch/69351/ > > > > > > The source of the problem is just changing log levels dynamically > > > is not possible currently with PCI driver logs. > > > > Assuming if we add, dynamic stuff what would the default log level for > > RTE_LOG(INFO, EAL, "PCI device "PCI_PRI_FMT" on NUMA socket %i\n", > > > > If it is INFO, Still the problem persist in the default bootup. Right? > > Yes > > We need to know in INFO level which devices are successfully probed. > You want to decrease to DEBUG the level of logs announcing a probe. > I think it would be OK if adding an INFO log after probe success.
OK. I will send the v2 by changing the existing one as DEBUG and a successful probe as INFO. > > >
