Re: [dpdk-dev] [PATCH] eal: postpone vdev initialization

[Ferruh Yigit <ferruh.yigit@intel.com>]

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 <jerin.jacob@caviumnetworks.com>
> ---

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