From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ferruh.yigit@intel.com>
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by dpdk.org (Postfix) with ESMTP id C039F2BC8
 for <dev@dpdk.org>; Mon, 21 Nov 2016 10:55:00 +0100 (CET)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
 by orsmga104.jf.intel.com with ESMTP; 21 Nov 2016 01:54:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.31,674,1473145200"; d="scan'208";a="903880561"
Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57])
 ([10.237.220.57])
 by orsmga003.jf.intel.com with ESMTP; 21 Nov 2016 01:54:57 -0800
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, dev@dpdk.org
References: <1479628850-27202-1-git-send-email-jerin.jacob@caviumnetworks.com>
Cc: declan.doherty@intel.com, david.marchand@6wind.com,
 thomas.monjalon@6wind.com
From: Ferruh Yigit <ferruh.yigit@intel.com>
Message-ID: <2bc2559f-5e83-5deb-65f9-750b78a0254a@intel.com>
Date: Mon, 21 Nov 2016 09:54:57 +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: <1479628850-27202-1-git-send-email-jerin.jacob@caviumnetworks.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 09:55:01 -0000

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