From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 7220E1BE0 for ; Wed, 17 Jan 2018 11:11:29 +0100 (CET) Received: by mail-wm0-f67.google.com with SMTP id 143so13958689wma.5 for ; Wed, 17 Jan 2018 02:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=Pl5HvFj1GxNk3jGSW2urp32qqeNhAb/N8P3kUp+22Y0=; b=hoQ0zcq4+1T41uIe6vKg4Uug9p7iMt1TUXR+iL24aVpbp9os9nJsPJ0yIkhUgNMM2L oCPYinUgtm+v4mhcuPVA6Auv7qpSewAIz+631kUkzbzNiy6Lo9Z36YOgpDQEKBL1HkNk EKBBUmqxKYhE9gdcI8VZ2N/+GN4XLNOICexZpGxPBDj53JhqFVAqta2tkvSi6knoQup4 T+q+Bt54F9VS9T6rpwSdhXrjhD6/H2DGgGv6+enARAsOrZkoweGjxEOZIwZuhsnIg/jR +Lq0zqPVHvNwuZL4CKw7ZK8PpXsgbyGsVBXr9H6Di1PDVBySnyjnmfuIP7FpV+N5Qz0d Bjag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=Pl5HvFj1GxNk3jGSW2urp32qqeNhAb/N8P3kUp+22Y0=; b=O7XAdV7DpGe0bTlxPGLNVeqGNZ1mIRQg7U3Ns1jTwZbFyiKa7MbenjzQb+K4TjWqFW +fgMX/M0WT23HMimGEtQsOczhO8T3FivUtvpKRw6ylFX/vjtC7iWlvpr4k0wwHfPigRt EemaV/13M9c5z1fmj9cT7+qOClBzZJr3epEoOPogesSqYIPu5WuhxmK/bvShI0fy65KB Ds1rl4MYA4pL7oLm9uk4TS62Hd6dk8rMlp3pGhDm90WYDP9+jp1xEqI9j5YJGnGx+C3T qnm0sH0tpc3eG3tWTNnVspOVEiufXHJ3sFSHSYReBbKNbBsmTNbGZNL/kJpx8u0kTiqO vUvA== X-Gm-Message-State: AKwxytdJvcrIfb3o4QcI+iTvo4QQCS+S676TJaT8Lk+DZRNHCvjYwC8/ hNooujXQwhjhAAq9vONPhrxFoQ== X-Google-Smtp-Source: ACJfBotA9bXe4J9rEFcNubp612qqAlhVVRrXy7zfZDYoHJ4H3ghUXseEOWCl1+jxrOfu0ptdNg2RfA== X-Received: by 10.80.228.74 with SMTP id e10mr2221954edm.20.1516183888760; Wed, 17 Jan 2018 02:11:28 -0800 (PST) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id b30sm3071112ede.53.2018.01.17.02.11.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Jan 2018 02:11:27 -0800 (PST) Date: Wed, 17 Jan 2018 11:11:15 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Yuanhan Liu Cc: dev@dpdk.org, Thomas Monjalon Message-ID: <20180117101115.o3jl7kmbse3hv5db@bidouze.vm.6wind.com> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> User-Agent: NeoMutt/20170113 (1.7.2) 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:11:29 -0000 A new suggestion about the syntax. 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. > > The new devargs proposal is introduced for having a consistent > interface for: > > - whitelisting/blacklisting devices > - identifying ports > - attaching/detaching devices > > 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 > > This syntax is suggestd by Thomas: > http://dpdk.org/ml/archives/dev/2017-December/084234.html > > Signed-off-by: Yuanhan Liu > --- > doc/guides/prog_guide/env_abstraction_layer.rst | 34 +++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) > > diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/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 such case, calling > callback. Care must be taken not to close the device from the interrupt handler > context. It is necessary to reschedule such closing operation. > > +Devargs > +~~~~~~~ > + > +The ``devargs`` can be used for whitelisting/blacklisting devices, identifying > +DPDK ports and attaching/deatching devices. They all share the same syntax. > + > +It is split in 3 categories, where almost everything is optional key/value 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=pci, must be placed before > +id=0000: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=pci,id=0000:01:00.0/class=eth,mac=00:11:22:33:44:55/driver=PMD_NAME,driverspecificproperty=VALUE > + > +It can also be simple like below:: > + > + class=eth,mac=00:11:22:33:44:55 > + 1/ All categories are named, their order is known, and their name comes first. It is thus possible to declare categories unambiguously without using the field name first. pci,id=0000:01:00.0/eth,mac=00:11:22:33:44:55/PMD_NAME,driverspecificproperty=VALUE eth,mac=00:11:22:33:44:55 pci,id=00:02.0 The only requirement for this to hold is for the layer names not to collide (bus, dev, drivers), which seems like an easy enough requirement to follow. ------------------------------- > +A device is identified when every properties are matched. Before device is > +probed, only the bus category is relevant. > + 2/ When using the following ID: class=eth,mac=00:11:22:33:44:55 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? What I mean is that a user could then do driver=net_ring To find the one port using the driver net_ring. ------------------------------- 3/ The driver would generate a name for the eth_dev structure. I guess it would be possible to identify the device with class=eth,name=net_ring0 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? -- Gaëtan Rivet 6WIND