From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) by dpdk.org (Postfix) with ESMTP id D107E1B2CC for ; Wed, 17 Jan 2018 00:46:46 +0100 (CET) Received: by mail-wr0-f171.google.com with SMTP id g38so13846463wrd.2 for ; Tue, 16 Jan 2018 15:46:46 -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=YeNTiwWSFwMgo3wZem3BlknQfiMUnZoH0A3jki4oZTA=; b=XPl0sPcAD/Co37FjYZf5HLXzaGFNk3qi/gEBeTpFACh9dsABpl6EixRolpudFQuhYY vB5aa4Aq12yrnvKLDtEUbyqWfeJMV6eYzfYk8c10u9CrdGY9r6+vjxuVskuqI2bUAGLh oAaAHu43EeaLmjhfeppn8k5Gu230Lbd3hHzjWRtcZx0o3WB+zTea7iVWTFAVK4raROJX sxFJBup5HWLZ7qxysVvh2Rg1SY0joisiRs7/T01T4WyIJT9Cd66T4xlFUkrukY+/uvZ3 9/wbR8mqDy9fzko8qMnXZP+oWxyKbSeim/s7C9ciFZ15JzY+xymVNZE5HTLynim0Y5RJ dBeQ== 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=YeNTiwWSFwMgo3wZem3BlknQfiMUnZoH0A3jki4oZTA=; b=uZFMjdE/Nvuvb79wIDHE5VqAZsufzzCHAYk7Cf/Mucs8u7eNqBQ97q489wEQJc+ash 4oieLXgmhnOmdDaj+PO4Cld4N2LsvN4Id0VZg1nmta0czexQmQQNWtsXvLhijMiQLND7 EWDCkORc9TpD9X4/C6u7LVP9r4ln+JwilAz8WYgxQEbbmuk4v2zfORjVVsUgO4K08ueW aCq4sbxasknXq3Oq5vKiPk+RfDj9MU2iwtI5Id7Rt1B0T/2CtZfdZBof8TA+J0XMIPFh XT/gPIOtXOtcG810dIYZta0GN5H1iXcZLlUCkQ8A7TgRVp/1xWyitZag3SRN7KlhgQN0 eFhg== X-Gm-Message-State: AKwxytd5GD/Jkf7WxmvGx/o9u6yAZlMn/NyLnRvR8dEjPMenMMm2PCcZ NyOI2bVxQTwhxF/fT0oSOjNt4iea X-Google-Smtp-Source: ACJfBos013N2gzCCOoErr+WH8S7LsEGsyqMzhkt+hd5fFWcxE97jImRT+bMbJ7C1ssy/gql/oQz3Ag== X-Received: by 10.223.145.133 with SMTP id 5mr705179wri.159.1516146406457; Tue, 16 Jan 2018 15:46:46 -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 t20sm2197767wrg.26.2018.01.16.15.46.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Jan 2018 15:46:45 -0800 (PST) Date: Wed, 17 Jan 2018 00:46:33 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Thomas Monjalon Cc: Yuanhan Liu , dev@dpdk.org Message-ID: <20180116234633.i4j2itsuzxk7kl35@bidouze.vm.6wind.com> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> <20180116231935.pucguvf4u6umvwgu@bidouze.vm.6wind.com> <5324030.qnTS7Rnbq7@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5324030.qnTS7Rnbq7@xps> 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: Tue, 16 Jan 2018 23:46:47 -0000 On Wed, Jan 17, 2018 at 12:22:43AM +0100, Thomas Monjalon wrote: > 17/01/2018 00:19, Gaëtan Rivet: > > Hi Yuanhan, > > > > On Tue, Jan 16, 2018 at 10:50:18PM +0800, Yuanhan Liu wrote: > > > +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 might be a nitpick, but the driver specific properties might not > > follow the key/value pair syntax. At least for the fail-safe, a custom > > parsing needs to happen. I think vdev in general will need flexibility. > > What is more flexible than key/value? > fail-safe does not need something more flexible, but different. It needs to define substrings describing whole devices, thus substrings following the aforementioned syntax. I choose to use ( and ) as markers of beginning and end of the "special sub-device part that we need to skip for the moment". In the end, I need a way to mark the beginning and the end of a parameter. Without this, the next parameter would be considered as the parameter of the sub-device, not of the fail-safe. = separated key/value pair does not allow for this (or with very convoluted additional rules to the syntax). > > There could be a note that after the comma past the eventual > > "driver=xxxx" pair, the syntax is driver-specific and might not follow > > the equal-separated key/value pair syntax. > > Please give an example. bus=vdev/driver=failsafe,dev(bus=pci,id=00:02.0),fd(/some/file/) Here, without some kind of "end-of-parameter" mark, fd() would be considered as a new parameter of the sub-device 00:02.0 -------------- And while I'm at it, there is an ambiguity that might need to be defined before the whole shebang is implemented: whether the parameters positions are meaningful or not. Currently some drivers might consider their parameters to mean different things depending on their order of appearance. It could help to explicitly say that the order is asemic and should not be considered by drivers. Why this is important: I think that depending on the new rte_devargs representation, it could be beneficial to have a canonical representation of an rte_devargs: given an arbitrary string given by users, the devargs could then be rewritten in a determinist way, which would help implementing comparison, assignment, and some other operations. However, for this canonicalization to be possible, order needs to be explicitly said to be meaningless. -- Gaëtan Rivet 6WIND