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 Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com> --- lib/librte_eal/common/eal_common_tailqs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/librte_eal/common/eal_common_tailqs.c b/lib/librte_eal/common/eal_common_tailqs.c index ead06897b8..55bfc70db4 100644 --- a/lib/librte_eal/common/eal_common_tailqs.c +++ b/lib/librte_eal/common/eal_common_tailqs.c @@ -155,7 +155,8 @@ rte_eal_tailqs_init(void) /* second part of register job for "early" tailqs, see * rte_eal_tailq_register and EAL_REGISTER_TAILQ */ rte_eal_tailq_update(t); - if (t->head == NULL) { + if (t->head == NULL && + rte_eal_process_type() == RTE_PROC_PRIMARY) { RTE_LOG(ERR, EAL, "Cannot initialize tailq: %s\n", t->name); /* TAILQ_REMOVE not needed, error is already fatal */ -- 2.17.1
On Thu, Jan 14, 2021 at 8:24 AM Hemant Agrawal <hemant.agrawal@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?
--
David Marchand
On 1/14/2021 7:14 PM, David Marchand wrote:
> On Thu, Jan 14, 2021 at 8:24 AM Hemant Agrawal <hemant.agrawal@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.
On Mon, Jan 18, 2021 at 6:55 AM Hemant Agrawal
<hemant.agrawal@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.agrawal@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.
--
David Marchand
On Thu, 25 Mar 2021 15:16:47 +0100
David Marchand <david.marchand@redhat.com> wrote:
> On Mon, Jan 18, 2021 at 6:55 AM Hemant Agrawal
> <hemant.agrawal@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.agrawal@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.
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.marchand@redhat.com> wrote:
>
> > On Mon, Jan 18, 2021 at 6:55 AM Hemant Agrawal
> > <hemant.agrawal@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.agrawal@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