From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ferruh.yigit@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id 741BBB6D
 for <dev@dpdk.org>; Mon, 21 Nov 2016 18:36:02 +0100 (CET)
Received: from fmsmga005.fm.intel.com ([10.253.24.32])
 by orsmga101.jf.intel.com with ESMTP; 21 Nov 2016 09:36:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.31,528,1473145200"; d="scan'208";a="34061872"
Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57])
 ([10.237.220.57])
 by fmsmga005.fm.intel.com with ESMTP; 21 Nov 2016 09:35:59 -0800
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
References: <1479628850-27202-1-git-send-email-jerin.jacob@caviumnetworks.com>
 <2bc2559f-5e83-5deb-65f9-750b78a0254a@intel.com>
 <20161121170202.GB5717@svelivela-lt.caveonetworks.com>
Cc: dev@dpdk.org, declan.doherty@intel.com, david.marchand@6wind.com,
 thomas.monjalon@6wind.com
From: Ferruh Yigit <ferruh.yigit@intel.com>
Message-ID: <fb64cdec-f086-896a-3463-6d23bdea440b@intel.com>
Date: Mon, 21 Nov 2016 17:35:58 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161121170202.GB5717@svelivela-lt.caveonetworks.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [dpdk-dev] [PATCH] eal: postpone vdev initialization
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Nov 2016 17:36:02 -0000

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@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
>