On 11/21/2016 5:02 PM, Jerin Jacob wrote: > On Mon, Nov 21, 2016 at 09:54:57AM +0000, Ferruh Yigit wrote: >> 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 at 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? > > I guess it may be effected only to ethdev bond pmd based application, > which is broken anyway.
My concern is, this may effect the applications that use "--vdev" eal parameter and has an assumption about port assignment. And if this breaks any userspace application, does it require a deprecation notice? > Let me know what it takes to make forward progress on this patch. I can > fix the same in v2. > > Jerin >
