From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25]) by dpdk.org (Postfix) with ESMTP id CA20D1B026
for <dev@dpdk.org>; Wed, 17 Jan 2018 10:43:55 +0100 (CET)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id 3EE6420D16;
Wed, 17 Jan 2018 04:43:55 -0500 (EST)
Received: from frontend1 ([10.202.2.160])
by compute1.internal (MEProxy); Wed, 17 Jan 2018 04:43:55 -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=I2FxB1Pu2DGq+NRBrcnhJjcxE2
8zrTrhlvx8AVo7F2o=; b=CbGFjhAErJs7Om9398ULxVraxLkpExhhhal21fJ/XE
ikbrGHn9BJNJ3Ly09M1aXbqzevpvJ/sLEm6cVvaYiiHDib/qWWwKu5z7+9jXj+YB
VVCjrD0Pt1Bkqio7RD+g2LUWbTm/6RXe5FgTqcGc4vE4MULMgrN2ZYYjIlxG9/V7
A=
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=I2FxB1
Pu2DGq+NRBrcnhJjcxE28zrTrhlvx8AVo7F2o=; b=sXeci6Lq4+qIBtjwEiOKkY
kiOLXv++bhDyB7b4mgBzgYGLfTTcdT19MUgl4jOWKExKQx/D0M6OtBn66CkltWoH
59L/bHRDH9RnsiwIdI31lO94ugd9CJbCuWC2FTgMzXeqACQb+eMOkIobGUuBotYq
X46sz3Rws7L59d7vU0roPgNHHIppNIG9Rdj86oPQiQLqOL1iTruaOjtChUhngxxO
lzK2LOfYflyrSL3huNghSR1rle4eOE4yTpMkF+vQiNEBzQ4h7bZCgr+omTyMex5n
+nfdoYDL8DgQ8S56SSxkF0Hbr9wdzdM1L4ACdve2bGe4QJzy/zksmiBs12TzdfCA
==
X-ME-Sender: <xms:2xpfWkBQjQMT0yN7P_lBHaDR0gDnpk_FLRFEkZpZJlxqv9dl9Nt8qw>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
by mail.messagingengine.com (Postfix) with ESMTPA id D50E47E43A;
Wed, 17 Jan 2018 04:43:54 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com>
Cc: Yuanhan Liu <yliu@fridaylinux.org>, dev@dpdk.org
Date: Wed, 17 Jan 2018 10:43:23 +0100
Message-ID: <3880793.9nSlzmWI4v@xps>
In-Reply-To: <20180117093749.upv2k6ew5tbvwdsp@bidouze.vm.6wind.com>
References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org>
<4760784.sYhQ8SkhdB@xps>
<20180117093749.upv2k6ew5tbvwdsp@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 <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2018 09:43:56 -0000
17/01/2018 10:37, Ga=EBtan Rivet:
> Hi Thomas,
>=20
> On Wed, Jan 17, 2018 at 01:03:50AM +0100, Thomas Monjalon wrote:
> > 17/01/2018 00:46, Ga=EBtan Rivet:
> > > On Wed, Jan 17, 2018 at 12:22:43AM +0100, Thomas Monjalon wrote:
> > > > 17/01/2018 00:19, Ga=EBtan Rivet:
> > > > > It might be a nitpick, but the driver specific properties might n=
ot
> > > > > follow the key/value pair syntax. At least for the fail-safe, a c=
ustom
> > > > > parsing needs to happen. I think vdev in general will need flexib=
ility.
> > > >=20
> > > > What is more flexible than key/value?
> > >=20
> > > fail-safe does not need something more flexible, but different.
> > > It needs to define substrings describing whole devices, thus substrin=
gs
> > > following the aforementioned syntax.
> > >=20
> > > I choose to use ( and ) as markers of beginning and end of the "speci=
al
> > > sub-device part that we need to skip for the moment". In the end, I n=
eed
> > > 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.
> > >=20
> > > =3D separated key/value pair does not allow for this (or with very
> > > convoluted additional rules to the syntax).
> >=20
> > OK, I agree we need beginning and end markers.
> > I wonder whether we should consider devargs as a specific case of value.
>=20
> Not sure I follow: you would want to consider a different syntax whether
> we are defining or identifying a device?
>=20
> This seems dangerous to me, a single unifying syntax should be used. But
> I probably misunderstood.
No, I'm just saying that it is a more generic problem:
values can contain some characters used in this syntax.
So yes, we need to protect them with parens (or braces).
> > Maybe we just want to allow using marker characters inside values.
>=20
> That would be nice. That, or allow drivers to use arbitrary parameters,
> by freeing the last field (past the "driver" token of the last
> category).
>=20
> Do you have a justification for restricting drivers parameters? Why
> couldn't this only be structured by commas (or any separators), and other=
wise
> left to the drivers to do as they see fit?
User experience.
I don't think key/value is restricting.
> > So we can use parens or quotes to optionnaly protect the values.
> > But as the shell developers learned, parens are better than quotes in
> > the long term because it allows nested expressions.
>=20
> This was the initial reason for using parens in the fail-safe, yes.
>=20
> However, any paired symbol could do, and parens do not actually play
> nice within a command in shell (the shell keep trying to capture the
> parens for its own parsing).
>=20
> The usual alternative was to use {}. I'd vote for this.
Yes braces are also OK.
> > > > > There could be a note that after the comma past the eventual
> > > > > "driver=3Dxxxx" pair, the syntax is driver-specific and might not=
follow
> > > > > the equal-separated key/value pair syntax.
> > > >=20
> > > > Please give an example.
> > >=20
> > > bus=3Dvdev/driver=3Dfailsafe,dev(bus=3Dpci,id=3D00:02.0),fd(/some/fil=
e/)
> > >=20
> > > Here, without some kind of "end-of-parameter" mark, fd() would be
> > > considered as a new parameter of the sub-device 00:02.0
> >=20
> > Right.
> > I think an equal sign is missing between "dev" and parenthesis.
> >=20
> > > --------------
> > >=20
> > > And while I'm at it, there is an ambiguity that might need to be defi=
ned
> > > before the whole shebang is implemented: whether the parameters
> > > positions are meaningful or not. Currently some drivers might conside=
r their
> > > parameters to mean different things depending on their order of appea=
rance.
> > >=20
> > > It could help to explicitly say that the order is asemic and should n=
ot
> > > be considered by drivers.
> > >=20
> > > Why this is important: I think that depending on the new rte_devargs
> > > representation, it could be beneficial to have a canonical representa=
tion
> > > of an rte_devargs: given an arbitrary string given by users, the deva=
rgs
> > > could then be rewritten in a determinist way, which would help implem=
enting
> > > comparison, assignment, and some other operations.
> > >=20
> > > However, for this canonicalization to be possible, order needs to be
> > > explicitly said to be meaningless.
> >=20
> > Good idea. I vote for meaningless ordering, except the first property
> > of each category, which describes the category.
>=20
> Agreed.