From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id A95412904 for ; Tue, 23 Jan 2018 13:46:09 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C96252103F; Tue, 23 Jan 2018 07:46:08 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 23 Jan 2018 07:46:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fridaylinux.org; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4fjhrU7KA0z5kz26n ErtjmMkhAP1WwOaqz4QDJ+tkzU=; b=hbEhL4BsEsndiiXc8Ao9LzGeIyiOtBya6 ptOuhlJgBEuD0GaHzhC10dgwGUcFtkaXD9Yd+6wpu2o0PteqElOd4RHfKXYzsWnv 3OjUZxoqwrEeDk9Ba0TeCL7aERZC8qkrdFFdpEoFtWXkJ3DB9oOt574kjEQCX123 A3iB1mWxrwqV0tT35Rp9TgR1PMtVxP9utjcYex4QCzCCrQdDj1DPmgpndrB6neib gWOhTirfCsiYz08ad6qsNunwWo0TPL3Y40YFhQ15o9XHbE7L/poyJb82VoWT+7O8 wBO0RBTFd//hkyrcvIDjwgaXT/7EhZrVV3rGAvUnTnlBe63SzLtyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4fjhrU 7KA0z5kz26nErtjmMkhAP1WwOaqz4QDJ+tkzU=; b=dXQMSKxfKZwDXlo3HMcktL S6PjyJpE6FSnuxp2JDEFYjsgcN7jcDw98RWbGIeYeMxPZEt/En0fKiBimpf0i2zC 7zGwo9GruLclJfptNIVu4Mj0X53O8/DiGlSO/O5v91Kmeadi0v3N+6aoVnQ+A/H9 XQxddqZHQLjZsIVZZywyfP3svBeTkBt4nMeue9mhUk2PJeGCEt2bFbP8J4VKRxzn O5j+yHKrJZbeb0qpkBpHicYrJWdvVVYAgJ55o/caQtmN2cqEtpDUPX4HlJ1Ry7tE O52A4oNAXorRmIHOH6V+ip//sx7z6c1AgiHgHkvUOFzG2gjSdcaV5eVlm5g8J+OQ == X-ME-Sender: Received: from yliu-mob (unknown [115.150.27.206]) by mail.messagingengine.com (Postfix) with ESMTPA id 3861E7E13A; Tue, 23 Jan 2018 07:46:06 -0500 (EST) Date: Tue, 23 Jan 2018 20:46:02 +0800 From: Yuanhan Liu To: =?iso-8859-1?Q?Ga=EBtan?= Rivet , Thomas Monjalon Cc: Ferruh Yigit , dev@dpdk.org Message-ID: <20180123124602.GS29540@yliu-mob> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> <68453aa8-de09-c41b-0b84-82eb6bbe19ac@intel.com> <20180118073520.GZ29540@yliu-mob> <1649717.sl7PR1QSdr@xps> <20180118094623.gu5ahrfd75b5gcct@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180118094623.gu5ahrfd75b5gcct@bidouze.vm.6wind.com> User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [dpdk-dev] [PATCH] doc: document the new devargs syntax 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: Tue, 23 Jan 2018 12:46:09 -0000 On Thu, Jan 18, 2018 at 10:46:23AM +0100, Gaëtan Rivet wrote: > On Thu, Jan 18, 2018 at 09:46:29AM +0100, Thomas Monjalon wrote: > > 18/01/2018 08:35, Yuanhan Liu: > > > On Wed, Jan 17, 2018 at 12:34:08PM +0000, Ferruh Yigit wrote: > > > > So does it make sense to separate them logically? Perhaps as "device identifier" > > > > and "device args". > > > > > > Then I think it returns back to the old issue: how could we identify a > > > port when the bus id (say BDF for PCI bus) is not enough for identifying > > > a port? Such case could happen when a single NIC has 2 ports sharing > > > the same BDF. It could also happen with the VF representors that will > > > be introduced shortly. > > > > Yes, the device matching syntax must include bus category, class category > > and driver category. So any device can be identified in future. > > > > But I think Ferruh is talking about separating device matching > > (which is described in this proposal) and device settings > > (which are usually mixed in -w and --vdev options). > > I agree there are different things and may be separate. > > They could share the same syntax (bus/class/driver) but be separate > > with a semicolon: > > matching;settings > > Can you give an example? Let's take port addition in OVS-DPDK as an example. It happens in 2 steps: - port lookup (if port is already probed) - dev attachment (if lookup fails) And also let's assume we need probe a ConnectX-3 port. Note that for ConnectX-3, there are 2 ports sharing the same PCI addr. Thus, PCI BDF is not enough. And let's assume we use another extra property "port". If the proposal described in this patch is being used, the devarg would look like following: bus=pci,id=04:00.0/class=eth,port=0/driver=mlx4,mlx4_arg_A=val,... Then "bus=pci,id=04:00.0/class=eth,port=0" will be used for lookup, It means we are looking for a port with PCI BDF == 04:00.0 AND port == 0 (the first port of the 2 ports). Note that in my proposal the driver category is not intended for lookup. If any properties needed be looked in the driver category, they would probably need be elevated to the class category. If port not found, then the whole string will be used for dev attachment. It means we are attaching a port with PCI BDF == 04.00.0 AND port == 0 (the 2nd port will not be attached). And here is how the devargs would look like if "matching;settings" is being used: bus=pci,id=04:00.0/class=eth,port=0;bus=pci,id=04:00.0/class=eth,port=0/driver=mlx4,mlx4_arg_A=val,... The part before ";" will be used for lookup and the later part will be used for attachment. It should work. It just looks redundant. -yliu