From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f193.google.com (mail-wr0-f193.google.com [209.85.128.193]) by dpdk.org (Postfix) with ESMTP id DB25C3B5 for ; Wed, 15 Feb 2017 21:06:54 +0100 (CET) Received: by mail-wr0-f193.google.com with SMTP id k90so32386357wrc.3 for ; Wed, 15 Feb 2017 12:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=VQo1AaRJ0nyCwPNRFrMSDMslZ29OvmZzuG/zD/c7bQs=; b=oQzDNXtG3qyLuyQ0Rz+mwiMlnqs80LEQFQ+9IzbeFAeY4ZdErFUCtWAYta4KfVEvCr RCE3sxnybSzJg7i5RWiBL7bGbjSbIjqoQSO+tzTj/GiB8rA4c8fk61BE6plnOEESard8 Zme/5YCEgYMHprTdfcvlKhwvVBImNw1dvgEHS7Nmr1qSB13hSVEshuO9uivnfxP8dTyZ 8wiPPls+cLn3454eayGavqLnBhsyUd5LxxbYAcXTx+4bVi1aRFrPmBfhVQKSvKWdG5nz tpkeqtSjt9I97DtVQPN1S4pituHJU077yM9p36eVTk8iaCIyJx8oIUeIxU90/j53bVX7 6A0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=VQo1AaRJ0nyCwPNRFrMSDMslZ29OvmZzuG/zD/c7bQs=; b=dDY9IXXuhuYM5hs2daa0lv1XvU8xRSI2QCtxhM+hWMNzo86uRBiYSkkyBXTYdiTsqY jIMwlV7I/nBfILfdZiNNheHWWG2f2mfUOJQaKuc9lOzXWgj5zU8TGqaIrcolKxRfuheD WI6j7xA4//ebS98rhtYPawDpY29eSrftMA0mbjfpdrPRqbtV+E+ojvvsU0y7EkJtEnvw 6qMi1s51VnLP0W2uy1IiOn8lG+qpa3z1j2rvKZ1jUp3WBKVqDYxwOe15GVG7P8P6IJCS D3VxOeYX6D/XE75T36NzlxNhHpWwCm1ve+kwBsJ+6ktKFn14IMuD9rfMm/64+/7FoKf+ i7tg== X-Gm-Message-State: AMke39k1VRXLp4+FOUGKkQRwY7n5SYlWZUTMUmd0yF45D47NZt88jqdlKXL+RZSWYHQICtE9M+KR8tLob/L7Jg== X-Received: by 10.223.161.93 with SMTP id r29mr8397404wrr.3.1487189214515; Wed, 15 Feb 2017 12:06:54 -0800 (PST) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.211.20 with HTTP; Wed, 15 Feb 2017 12:06:53 -0800 (PST) In-Reply-To: <9AE1640E-5F5D-446F-A304-F94D6667FC02@intel.com> References: <1487152929-23627-1-git-send-email-jblunck@infradead.org> <1487152929-23627-4-git-send-email-jblunck@infradead.org> <485202cf-3644-5ee9-45b5-d443569bf5b5@nxp.com> <7843A545-14B6-4CD9-9689-ABD123B85890@intel.com> <20170215172530.GA8119@localhost.localdomain> <9AE1640E-5F5D-446F-A304-F94D6667FC02@intel.com> From: Jan Blunck Date: Wed, 15 Feb 2017 21:06:53 +0100 X-Google-Sender-Auth: oOtMD0fAHBeI5Ql0cmBHI9grbpg Message-ID: To: "Wiles, Keith" Cc: Jerin Jacob , Shreyansh Jain , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH 3/7] eal: move virtual device probing into a bus X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 20:06:55 -0000 On Wed, Feb 15, 2017 at 7:09 PM, Wiles, Keith wrote= : > > I guess I see this differently, meaning we modified the system to put vde= v devices last only because we do not have clean way to startup the system = for pdev/vdev devices. The application should be agnostic to the devices be= ing started and the system needs to determine the correct order without a c= hicken and egg problem. The test-pmd application just starts from 0 to n to= initialize devices, which he should be able to do in any order. It is poss= ible the application could initialize the devices (pdev/vdev) in any order,= which the current design would break if they tried to init the bonding dri= ver first. > Apart from the usability (vdevs always first) I wonder what kind of usecase you are after. If I understand you correctly you want to: - probe the virtual devices first - start/configure the virtual devices last ... and only in some cases. From what I understand this requires a domain specific way to model dependencies between ports, e.g. some standardized device arguments parsed by EAL, and combined with your requirement to assign the lowest port numbers for the vdev devices even a scheduler. Maybe we could reduce complexity by doing some simple things instead: if you present the ports in reverse order to the users the vdev come first. Probably this even increases usability because the most recent created port is the one that the user is anyway most interested in. > What happens if a vdev needs to be initialized before a pdev device? > This should never happen. The pdev devices offer a plain view on the "system", which means no topology at all. The vdev devices are devices that do not have a "system" representation, e.g. a library. I don't think the EAL should offer an alternative API to system programming in a way that you enumerate your PCI devices through a vdev that is accessing hardware through another library. > Not saying we need to solve this problem now, but need to figure this out= some how. Maybe we need a priority for pdev/vdev devices to determine init= order???? >