[dpdk-dev] [PATCH] eal: postpone vdev initialization
Jerin Jacob
jerin.jacob at caviumnetworks.com
Mon Nov 21 17:56:40 CET 2016
On Mon, Nov 21, 2016 at 10:39:00AM +0530, Shreyansh Jain wrote:
> On Sunday 20 November 2016 01:30 PM, Jerin Jacob wrote:
> > Some platform like octeontx may use pci and
> > vdev based combined device to represent a logical
> > dpdk functional device.In such case, postponing the
> > vdev initialization after pci device
> > initialization will provide the better view of
> > the pci device resources in the system in
> > vdev's probe function, and it allows better
> > functional subsystem registration in vdev probe
> > function.
> >
> > As a bonus, This patch fixes a bond device
> > initialization use case.
> >
> > example command to reproduce the issue:
> > ../testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> > slave=0000:02:00.0,slave=0000:03:00.0' --
> > --port-topology=chained
> >
> > root cause:
> > In existing case(vdev initialization and then pci
> > initialization), creates three Ethernet ports with
> > following port ids
> > 0 - Bond device
> > 1 - PCI device 0
> > 2 - PCI devive 1
> >
> > Since testpmd, calls the configure/start on all the ports on
> > start up,it will translate to following illegal setup sequence
> >
> > 1)bond device configure/start
> > 1.1) pci device0 stop/configure/start
> > 1.2) pci device1 stop/configure/start
> > 2)pci device 0 configure(illegal setup case,
> > as device in start state)
> >
> > The fix changes the initialization sequence and
> > allow initialization in following valid setup order
> > 1) pcie device 0 configure/start
> > 2) pcie device 1 configure/start
> > 3) bond device 2 configure/start
> > 3.1) pcie device 0/stop/configure/start
> > 3.2) pcie device 1/stop/configure/start
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob at caviumnetworks.com>
> > ---
> > lib/librte_eal/bsdapp/eal/eal.c | 6 +++---
> > lib/librte_eal/linuxapp/eal/eal.c | 6 +++---
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
> > index 35e3117..2206277 100644
> > --- a/lib/librte_eal/bsdapp/eal/eal.c
> > +++ b/lib/librte_eal/bsdapp/eal/eal.c
> > @@ -577,9 +577,6 @@ rte_eal_init(int argc, char **argv)
> > rte_config.master_lcore, thread_id, cpuset,
> > ret == 0 ? "" : "...");
> >
> > - if (rte_eal_dev_init() < 0)
> > - rte_panic("Cannot init pmd devices\n");
> > -
> > RTE_LCORE_FOREACH_SLAVE(i) {
> >
> > /*
> > @@ -616,6 +613,9 @@ rte_eal_init(int argc, char **argv)
> > if (rte_eal_pci_probe())
> > rte_panic("Cannot probe PCI\n");
> >
> > + if (rte_eal_dev_init() < 0)
> > + rte_panic("Cannot init pmd devices\n");
> > +
> > rte_eal_mcfg_complete();
> >
> > return fctret;
> > diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
> > index 2075282..16dd5b9 100644
> > --- a/lib/librte_eal/linuxapp/eal/eal.c
> > +++ b/lib/librte_eal/linuxapp/eal/eal.c
> > @@ -841,9 +841,6 @@ rte_eal_init(int argc, char **argv)
> > rte_config.master_lcore, (int)thread_id, cpuset,
> > ret == 0 ? "" : "...");
> >
> > - if (rte_eal_dev_init() < 0)
> > - rte_panic("Cannot init pmd devices\n");
> > -
> > if (rte_eal_intr_init() < 0)
> > rte_panic("Cannot init interrupt-handling thread\n");
> >
> > @@ -887,6 +884,9 @@ rte_eal_init(int argc, char **argv)
> > if (rte_eal_pci_probe())
> > rte_panic("Cannot probe PCI\n");
> >
> > + if (rte_eal_dev_init() < 0)
> > + rte_panic("Cannot init pmd devices\n");
> > +
> > rte_eal_mcfg_complete();
> >
> > return fctret;
> >
>
> Movement looks fine to me.
>
> IMO, rte_eal_dev_init() is a misleading name. It actually performs a
> driver->probe for vdev - which is parallel to rte_eal_pci_probe.
Looks good to me. If there are no objection, I can change to rte_eal_vdev_probe()
as a separate patch in v2. Let the order change patch be separate.
>
> -
> Shreyansh
More information about the dev
mailing list