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 DBE531B017 for ; Thu, 18 Jan 2018 08:35:27 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8584B20CB4; Thu, 18 Jan 2018 02:35:27 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 18 Jan 2018 02:35:27 -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=205P4KxIUNmg/GvhNA2PZL11Gsn9uzk+3Ki0ay+0YIs=; b=gqIr+v+b EbmHq3EEdBiGQvLmf5O/EFYO2fDGAx7JuacZb+pWOplAIqtf3eW9A8x5t1KcgvBJ 3PQUWG4t9yLs9NFWFtCOlH84D9ILKeO5BPzwHEaVu9JZ5ftp9mmogLaxb4aPhnFJ 0/4QiFXspwrwuNArYMBx63xtCfPknWLwggEpXqZxu8QPOTEAc65hdA9ffKe0RSTu 95/A+HkNI2i1xSw2U/T2ht0gKE/6Oc5kZ/NK8H+Bacgmc9avjnc939qRR//tcqdt o46AqCGi73R/U2XbvVnrJ3rLSu49TFvHmN2dys8DuifU6cLWPwJ7luCmo27S5CqZ 7bDOD5LO1XhwjQ== 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=205P4KxIUNmg/GvhNA2PZL11Gsn9u zk+3Ki0ay+0YIs=; b=YKsGxFnRmJWyq4cujb5jp/W0iFDBXVWC9dHkGpAz7ILUD U3ErJ2a0xi4Gldt0ctvjP/EbmRiUQ25Fuxt6o/sxcHQLNfCR47AU4qyHAwQmZ2k5 J19ThXXLRq9lTKwW+akQCRXdHt95BsJeZ5MmD2itP0tCYDRIVonb9MfRWOn7jJ2E ldHh5eG/WJrKnnDDYXwqOp2xbmdJCxz1mg91BuNkhhCgDT6/Na14NEc8qhe1r42B FMl+i0uB5Lwhdro2/BZv053XlnZKZ9NdUzzQjn5W+efGkydTY0O4xZ/9EBkQqWOz Jet8rTnPYK+RdscrCHYOFtLH3loDCZhQrHJn4DMMw== X-ME-Sender: Received: from yliu-mob (unknown [115.148.90.22]) by mail.messagingengine.com (Postfix) with ESMTPA id 51479240F6; Thu, 18 Jan 2018 02:35:24 -0500 (EST) Date: Thu, 18 Jan 2018 15:35:20 +0800 From: Yuanhan Liu To: Ferruh Yigit Cc: dev@dpdk.org, Thomas Monjalon Message-ID: <20180118073520.GZ29540@yliu-mob> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> <68453aa8-de09-c41b-0b84-82eb6bbe19ac@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68453aa8-de09-c41b-0b84-82eb6bbe19ac@intel.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: Thu, 18 Jan 2018 07:35:28 -0000 On Wed, Jan 17, 2018 at 12:34:08PM +0000, Ferruh Yigit wrote: > On 1/16/2018 2:50 PM, 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 > > Hi Yuanhan, Hi Ferruh, > devargs = device arguments, the PMD specific arguments, similar to module_param > in Linux. Not exactly. If you look at the function rte_eth_dev_attach(const char *devargs, uint16_t *port_id), the "device identifier" part you called also part of the devargs. > > Currently only "--vdev" and -w/-b eal parameters parse proceeding strings as > devargs. > > Like: "--vdev "net_pcap,iface=lo" . > For this case "iface=lo" device specific argument and available to use from pcap > PMD. > > I agree it to have a consistent way to describe device, that makes better > whitelist/blacklist support. But that part is not device args, more like device > identifier. > > When you use this string with whitelist/blacklist I think you won't need > "iface=lo" part, Right. That's actaully mentioned in this patch: Before device is probed, only the bus category is relevant. > only need first part. And when using with --vdev, (or perhaps > with attach) you don't need to use first part > "bus=pci,id=0000:01:00.0/class=eth,mac=00:11:22:33:44:55", PMD already knows it > is in virtual bus and its class etc. We are going to keep the compatibily, meaning we will leave "-w" and "--vdev" as they are. We plan to introduce one more CLI option and let user to switch to it so that it can work with any bus, not only PCI and vdev bus. > 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. --yliu > string can become: > "device=bus=pci,id=0000:01:00.0/class=eth,mac=00:11:22:33:44:55;driver=PMD_NAME,driverspecificproperty=VALUE" > > specific usages can become: > -w "device=bus=pci,id=0000:01:00.0/class=eth,mac=00:11:22:33:44:55" > --vdev "driver=PMD_NAME,driverspecificproperty=VALUE" > > And store them in two separate storage, and eal or PMD can ask for "device > identifier" or "device args" separately? > > What do you think? > > > > > 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 > > + > > +A device is identified when every properties are matched. Before device is > > +probed, only the bus category is relevant. > > + > > Blacklisting > > ~~~~~~~~~~~~ > > > >