tailq: secondary process may not have all tailq available
Checks
Commit Message
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(-)
Comments
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?
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.
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
@@ -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 */