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 5CD3E1B172 for ; Wed, 17 Jan 2018 11:55:31 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 82EFE20EB1; Wed, 17 Jan 2018 05:55:30 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 17 Jan 2018 05:55:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; 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=mesmtp; bh=jZwAqaxZvT4q56jAg+JNmq8YhF /mMdYfUG10n7Zim/Q=; b=SQkxAbZz6oYFOypKNooi0zhPJSdv3Gz0C6akqEReuv gqsDxrpLKNeqGsKXlKHc7jZ7fhk7X7gq66kv6aiUGT1tAEcTVqLtdYBSfdXkdH2w BI8aG1Z5vwarrXtgEZYF+THPt0n5qSmyimI0G+kO0nahFszxa2locIRZMKThp0X3 4= 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=jZwAqa xZvT4q56jAg+JNmq8YhF/mMdYfUG10n7Zim/Q=; b=qhzkNzwg1pfXhBEasVWkVm xIW+7nnqoHVCMesJn9ujcWpIcvRVXULjYwLzfTU3TNMBChCYhYVtrFLxodDUcXFT qpyhiKRorgQp4OF5Iu9n4C/UJZoVhEyEbj7WOrZbag3bEA8BS0F5BoSKJ6GrS+eB H2DL3JXT0ikemKZvA/gs5rXKxFhF9ZjVOru9GQ2arvlpQIld2AmrjSO3vD8tNipA gNwEkeXX2fcrSm0Tf/Xv7gJ2/Hz0w5pMNjWyVioYtxGMkCZukmiqidm0+zCc8Bx/ ul/mhNzDd6Tgq3bZQeuqAZ2E5/UiNzEM05VlkFzbnCxB5GDixwavF/qKn/O6kn2g == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2C46724691; Wed, 17 Jan 2018 05:55:30 -0500 (EST) From: Thomas Monjalon To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Cc: Yuanhan Liu , dev@dpdk.org Date: Wed, 17 Jan 2018 11:54:58 +0100 Message-ID: <11685797.rhpIizAFUB@xps> In-Reply-To: <20180117101115.o3jl7kmbse3hv5db@bidouze.vm.6wind.com> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> <20180117101115.o3jl7kmbse3hv5db@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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, 17 Jan 2018 10:55:31 -0000 17/01/2018 11:11, Ga=EBtan Rivet: > A new suggestion about the syntax. >=20 > On Tue, Jan 16, 2018 at 10:50:18PM +0800, Yuanhan Liu wrote: > > This patch documents the new devargs syntax, which is going to be > > implemented in DPDK v18.05. > >=20 > > The new devargs proposal is introduced for having a consistent > > interface for: > >=20 > > - whitelisting/blacklisting devices > > - identifying ports > > - attaching/detaching devices > >=20 > > Please check the patch content for the details. Also, here is link > > for the background: > > http://dpdk.org/ml/archives/dev/2017-November/082600.html > >=20 > > This syntax is suggestd by Thomas: > > http://dpdk.org/ml/archives/dev/2017-December/084234.html > >=20 > > Signed-off-by: Yuanhan Liu > > --- > > doc/guides/prog_guide/env_abstraction_layer.rst | 34 +++++++++++++++++= ++++++++ > > 1 file changed, 34 insertions(+) > >=20 > > diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guid= es/prog_guide/env_abstraction_layer.rst > > index 34d871c..12f37f2 100644 > > --- a/doc/guides/prog_guide/env_abstraction_layer.rst > > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst > > @@ -213,6 +213,40 @@ device having emitted a Device Removal Event. In s= uch case, calling > > callback. Care must be taken not to close the device from the interrup= t handler > > context. It is necessary to reschedule such closing operation. > > =20 > > +Devargs > > +~~~~~~~ > > + > > +The ``devargs`` can be used for whitelisting/blacklisting devices, ide= ntifying > > +DPDK ports and attaching/deatching devices. They all share the same sy= ntax. > > + > > +It is split in 3 categories, where almost everything is optional key/v= alue pairs: > > + > > +* bus (pci, vdev, vmbus, fslmc, etc) > > +* class (eth, crypto, etc) > > +* driver (i40e, mlx5, virtio, etc) > > + > > +The key/value pair describing the category scope is mandatory and must= be the > > +first pair in the category properties. Example: bus=3Dpci, must be pla= ced before > > +id=3D0000:01:00.0. > > + > > +The syntax has below rules: > > + > > +* Between categories, the separator is a slash. > > +* Inside a category, the separator is a comma. > > +* Inside a key/value pair, the separator is an equal sign. > > +* Each category can be used alone. > > + > > +Here is an example with all categories:: > > + > > + bus=3Dpci,id=3D0000:01:00.0/class=3Deth,mac=3D00:11:22:33:44:55/dr= iver=3DPMD_NAME,driverspecificproperty=3DVALUE > > + > > +It can also be simple like below:: > > + > > + class=3Deth,mac=3D00:11:22:33:44:55 > > + >=20 > 1/ >=20 > All categories are named, their order is known, and their name comes > first. The order of categories is known but some categories may be omitted. > It is thus possible to declare categories unambiguously without using > the field name first. >=20 > pci,id=3D0000:01:00.0/eth,mac=3D00:11:22:33:44:55/PMD_NAME,driverspec= ificproperty=3DVALUE > eth,mac=3D00:11:22:33:44:55 > pci,id=3D00:02.0 >=20 > The only requirement for this to hold is for the layer names not to colli= de > (bus, dev, drivers), which seems like an easy enough requirement to follo= w. I don't like it for 2 reasons: =2D it is less explicit =2D it is less obvious to dispatch to parsers > ------------------------------- >=20 > > +A device is identified when every properties are matched. Before devic= e is > > +probed, only the bus category is relevant. > > +=20 >=20 > 2/ >=20 > When using the following ID: >=20 > class=3Deth,mac=3D00:11:22:33:44:55 >=20 > The bus is skipped, as well as the driver. > Does that mean that it is allowed to skip any layer, as long as the > resulting match is unambiguous? >=20 > What I mean is that a user could then do >=20 > driver=3Dnet_ring >=20 > To find the one port using the driver net_ring. I think yes, if there is only one net_ring device. > ------------------------------- >=20 > 3/ >=20 > The driver would generate a name for the eth_dev structure. > I guess it would be possible to identify the device with >=20 > class=3Deth,name=3Dnet_ring0 >=20 > Or something. Where does the rte_dev name appears? Is it a property > of the bus layer? Is it merged with the eth_dev name? If so, which one > will stay, the rte_dev name or the eth_dev name? EAL device and ethdev are different layers. There is no 1:1 mapping. So both must stay. rte_dev name should be a property of the bus layer.