On Wed, May 20, 2026 at 05:44:14PM +0200, David Marchand wrote: > 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. > Yes, true. Probably not worth the effort at this point.
/Bruce
