On 11/20/2016 8:00 AM, 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 <redacted>
---

This changes the port id assignments to the devices, right?

Previously virtual devices get first available port ids (0..N1), later
physical devices (N1..N2). Now this becomes reverse.

Can this change break some existing user applications?

Thanks,
ferruh