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

Jerin Jacob jerinjacobk at gmail.com
Sun Apr 26 20:48:38 CEST 2020


On Sun, Apr 26, 2020 at 11:37 PM Thomas Monjalon <thomas at monjalon.net> wrote:
>
> 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.

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?




>
>


More information about the dev mailing list