On Thu, Mar 25, 2021 at 09:05:51AM -0700, Stephen Hemminger wrote: > On Thu, 25 Mar 2021 15:16:47 +0100 > David Marchand <david.march...@redhat.com> wrote: > > > On Mon, Jan 18, 2021 at 6:55 AM Hemant Agrawal > > <hemant.agra...@oss.nxp.com> wrote: > > > On 1/14/2021 7:14 PM, David Marchand wrote: > > > > On Thu, Jan 14, 2021 at 8:24 AM Hemant Agrawal <hemant.agra...@nxp.com> > > > > wrote: > > > >> Secondary process may not have all the tailq available for > > > >> mapping, so better to ignore the error. > > > >> > > > >> e.g. if the primary process is linked with N libs > > > >> and secondary process is linked with less number of libs. > > > >> > > > >> dpdk-procinfo results into following error: > > > >> EAL: Cannot initialize tailq: VMBUS_RESOURCE_LIST > > > > For dpdk-procinfo to complain about vmbus, it means the bus driver has > > > > been loaded in the secondary, but not in the primary. > > > > Is this what you intend to do? > > > > > > > Yes. > > > > > > Typically the customer applications are built/linked with only limited > > > number of bus, devices > > > > > > dpdk-procinfo is getting compiled with default list as part of dpdk > > > build. so, if customer is trying to use the default dpdk-procinfo with > > > their application - there will be differences. > > > > > > > Is this a usecase that we support or we want to support? > > Thanks. > > > > > > Primary and secondary process have to be built with same DPDK version > and same configuration values.
I'd like to see support for the information provided by proc-info also exposed via telemetry callbacks, which would give us an easier way for tooling to request and process this data. Relying on something using the multi-process model is always going to have potential issues. /Bruce
