On Sun, Nov 20, 2016 at 9:00 AM, Jerin Jacob <jerin.jacob at caviumnetworks.com> 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
This patch is fine. It's been a while since I looked at the bonding pmd. I am just wondering if the bonding pmd should really start its slaves ports. -- David Marchand