[dpdk-dev] [PATCH] bus/pci: set boot-up log prints to absolute minimum

[Thomas Monjalon]

26/04/2020 19:42, Jerin Jacob:
> On Sun, Apr 26, 2020 at 1:42 AM Thomas Monjalon <thomas at monjalon.net> wrote:
> > 06/02/2020 15:36, Jerin Jacob:
> > > On Thu, Feb 6, 2020 at 7:44 PM Thomas Monjalon <thomas at monjalon.net> wrote:
> > > > 21/01/2020 09:00, jerinj at marvell.com:
> > > > > From: Jerin Jacob <jerinj at 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.

> 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.