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

[Ferruh Yigit]

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
>