On Tue, 19 May 2026 at 19:58, Bruce Richardson <[email protected]> wrote: > > On Sat, May 16, 2026 at 12:19:41PM +0200, David Marchand wrote: > > Some nics may not provide a serial number (PCI capability > > RTE_PCI_EXT_CAP_ID_DSN). > > > > This results in a confusing ERROR log: > > ICE_INIT: ice_dev_init(): Failed to read device serial number > > > > This is confusing as DDP loading does *not* require the serial number to > > be present for the port to be functional afterwards. > > > > Besides, after trying various path, if the default DDP is not present on > > the runtime system, the port initialisation ends up with a vague error: > > ICE_INIT: ice_load_pkg(): failed to search file path > > > > Improve the situation with adjusting the log level when reading the > > SN fails, then add more debug context to DDP file loading and end up > > with a ERROR log mentioning the expected file. > > > > ICE_INIT: ice_firmware_read(): Cannot read DDP file > > /lib/firmware/updates/intel/ice/ddp/ice-b49691ffffe6e69c.pkg > > ICE_INIT: ice_firmware_read(): Cannot read DDP file > > /lib/firmware/intel/ice/ddp/ice-b49691ffffe6e69c.pkg > > ICE_INIT: ice_firmware_read(): Cannot read DDP file > > /lib/firmware/updates/intel/ice/ddp/ice.pkg > > ICE_INIT: ice_firmware_read(): Cannot read DDP file > > /lib/firmware/intel/ice/ddp/ice.pkg > > ICE_INIT: ice_load_pkg(): Failed to load default DDP package > > /lib/firmware/intel/ice/ddp/ice.pkg > > > > Signed-off-by: David Marchand <[email protected]> > > --- > > drivers/net/intel/ice/ice_ethdev.c | 31 ++++++++++++++++++++---------- > > 1 file changed, 21 insertions(+), 10 deletions(-) > > > On top of the changes made in this patch, how about something like the > below to extend things? > > Rather than just debug logging the failed paths, we change the debug logs > to always log each load attempt. We also record the path as it's attempted, > and then on failure to load any path we use that record to print out an > error message for each failure, so the user can see in the error logs ALL > the failed paths, rather than having to re-run the app at debug level to > find them. > > WDYT?
That's a lot of code for something that is usually detected right at the first installation/run of your DPDK application. When you are at this point, restarting testpmd with the right debug level is the usual way. But let's say you can't restart your application, log levels can be changed dynamically (possible with testpmd, grout and OVS) before/after trying to probe the E810 device. -- David Marchand
