From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id EBA011B198 for ; Wed, 24 Jan 2018 16:04:33 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 41315223C9; Wed, 24 Jan 2018 10:04:33 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 24 Jan 2018 10:04:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fridaylinux.org; h=cc: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=+3vV3o72mpUok0LFPNVoD/xw5c+XqdE7AWQmqVN6YxU=; b=T38dswbc /uz2m2qYmT/WousV3Opt0appg0RcYkHa/fMup+1Vm4jpLIYxjkf1GWmKYq1VT1Rm d/1ULnMRULRFFmgLP4zW1tWTQghoadAYV+jUeqLeQfuwFpgsm2VveK6pISWhgUe2 NcI4DHw3OYbAetybf4m+C2d/isQNrpMFpRNiGbn8HTfRKgv2/+f2dzFeR7zMtBif JrIYRmkCxhAbGQgAHLBV3BSQY+3szIZ99XLZpmt06zuuznK3CykacaEkVmRKGoch Zu/Eec8iVFILNbDdQLc3JMqVSQtjM7aFFZqpVHxS8U05TtnjlCP7GZ58KFlej5Q3 dQ1XI0qLJ8JFrg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=+3vV3o72mpUok0LFPNVoD/xw5c+Xq dE7AWQmqVN6YxU=; b=dL1gWta3jVE6GOsetUlzAfUKDCB+7lxh1U4QgJ040L5dw WhQM8ywOC3cnw3nrxqY+m5Zx7wuw0K5a+PSXhYlF5BzFP2paOsqcD0fnj/CJb1i+ oNfGPBj3nqesR2t5peob2n7LbqIJNd28vcoh7Rf4/xf4qTj7jlXWsA82XaFxqsDo vyHjv92tzO9AtODJmHH4s4f4qm8iiK6mouTSzNL4uQYntFqamIu9dlVH/hcYtu8j eBNOkzDcZNsNiL0KZbqUw2fQsDnwu6MA8QzWWVFrlIoqLFWR5yhOYcqLUnoiN0dr n2EBMQHcpf7zxK7PL6U+D09lP8KOgBiYrtzoq1OtA== X-ME-Sender: Received: from yliu-mob (unknown [115.150.27.206]) by mail.messagingengine.com (Postfix) with ESMTPA id 299E124785; Wed, 24 Jan 2018 10:04:31 -0500 (EST) Date: Wed, 24 Jan 2018 23:04:28 +0800 From: Yuanhan Liu To: Thomas Monjalon Cc: =?iso-8859-1?Q?Ga=EBtan?= Rivet , Ferruh Yigit , dev@dpdk.org Message-ID: <20180124150428.GW29540@yliu-mob> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> <4742912.xRQpCbhV5k@xps> <20180124103640.GV29540@yliu-mob> <1680859.nSYTmhjtCR@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1680859.nSYTmhjtCR@xps> 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: Wed, 24 Jan 2018 15:04:34 -0000 On Wed, Jan 24, 2018 at 11:37:31AM +0100, Thomas Monjalon wrote: > 24/01/2018 11:36, Yuanhan Liu: > > On Wed, Jan 24, 2018 at 11:21:44AM +0100, Thomas Monjalon wrote: > > > 24/01/2018 10:28, Yuanhan Liu: > > > > On Wed, Jan 24, 2018 at 09:19:10AM +0100, Thomas Monjalon wrote: > > > > > 24/01/2018 07:43, Yuanhan Liu: > > > > > > On Tue, Jan 23, 2018 at 03:29:34PM +0100, Thomas Monjalon wrote: > > > > > > > 23/01/2018 13:46, Yuanhan Liu: > > > > > > > > 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. > > > > > > > > > > > > > > It does not have to be redundant. > > > > > > > It can be: > > > > > > > bus=pci,id=04:00.0/class=eth,port=0;driver=mlx4,mlx4_arg1=settings1,... > > > > > > > > > > > > I knew you would make such reply :) > > > > > > Then there is a contradiction. According your suggestion, the "port=0" belongs > > > > > > to the matching section, but it also has to be used in the settings section. > > > > > > > > > > If port=0 is matched, it is already set, right? > > > > > > > > Yes. > > > > > > > > > Why it needs to be in settings? > > > > > > > > But I was talking the case it's not matched, say it's not probed and here > > > > we do hotplug. > > > > > > I don't understand. > > > Anyway, the port property should be read-only. > > > > All proberties should be read-only. > > > > > Are we talking about the dev_port from the Linux kernel? > > > > Yes. And it can be used for probing one port only (out of 2 ports in a NIC) > > at probe stage. So, at this stage, it's a setting but not a match. > > No it's a match! > > A settings is changing data in the port. So I see that's your definition about the "settings". What I think is everything needed for driver initiation are settings. For example, one proposed interface for VF rep is the "vf_id" property, Similar to "port" property we have just discussed above, it's used for probing one specific VR rep for the given VF id. You can say it's a match here, just like the "port" property. But note that "vf_id" could be a range, to enable multiple VF reps. The semantics looks like "setting" more than "match". Another example is from the failsafe PMD that Gaetan had mentioned: driver=failsafe,dev(bus=pci,id=00:02.0),fd(/some/file/) They (dev and fd) should belong the "setting" section, for 2 reasons: - they should not be used for matching - they are used for failsafe PMD initiation But it belongs "match", according to your definition about "settings", because it doesn't change data in the port. That also means, the word "settings" might not be well named. It's probably better to name it "drvargs". --yliu