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 070731B365 for ; Fri, 22 Dec 2017 10:00:26 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7C22A20D5D; Fri, 22 Dec 2017 04:00:24 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 22 Dec 2017 04:00:24 -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=nWHduVSjz2+ukQP/XHNBDMtMsF 12y3PoYvihxqRNmYo=; b=Xa0Ssg7395ZbmKi0OnyjHqXoEMc/Re8L3t1gjnZgHm r1r0ftn/3sRhCoAaGVhPIT47vDpDyPKFrXBjToSaDkoQ+xplOHJ0w+8jwE8EpVI0 dQZlf8WKKBKubBGBE5MFi8NIE4LzFsPt9n9WiJx3FMElSS4SP5F53LYz+QtyZmcE s= 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=nWHduV Sjz2+ukQP/XHNBDMtMsF12y3PoYvihxqRNmYo=; b=XfyJh8jyCpK2gsQazyswfH oGS4eWslh4Gm3SVrlJdvBZuX837C7g3Te4xl/cXoqdZoZvtd0EkJL6D2u2k+q54b Zz4CDd4bytmnsMATgSZyV863cy3j4bD4zy+9gk0Q1SyhyBAEpSo6Ufwyi1OFERsR hBGR2mD38OhJB4Oy+ztHEruJziorDdLQ2NteA62EwLR2hmAEOzvnEUJge617X4Pe hNMezhqIWONKFkAPh8VBoBcH7iTFSPCuhDQH8+plur6k884LP7QdOlnjjnL2oR7z ulstf17Ux2VWM0z3ZYBEtaRidu8VEAiksliR7Mg2titkjxJgsiMpl/QXF/AY6H4g == 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 137337E101; Fri, 22 Dec 2017 04:00:24 -0500 (EST) From: Thomas Monjalon To: Shreyansh Jain Cc: dev@dpdk.org, Yuanhan Liu , Adrien Mazarguil , Ciara Loftus , Kevin Traynor , stephen@networkplumber.org, ferruh.yigit@intel.com Date: Fri, 22 Dec 2017 10:00:22 +0100 Message-ID: <4197715.cXtSenmrem@xps> In-Reply-To: <023a90af-bfcd-328d-4ed9-783ee76203fd@nxp.com> References: <1512027330-30030-1-git-send-email-yliu@fridaylinux.org> <7044959.u7szEIarlR@xps> <023a90af-bfcd-328d-4ed9-783ee76203fd@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] standardize device identification 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: Fri, 22 Dec 2017 09:00:26 -0000 22/12/2017 08:01, Shreyansh Jain: > On Thursday 21 December 2017 03:32 AM, Thomas Monjalon wrote: > > Changing the title and adding more comments inline: > > > > 19/12/2017 00:05, Thomas Monjalon: > >> Let's summarize and resume this thread. > >> > >> We need a generic syntax to describe a device. > >> This syntax can be used > >> - before initializing the device (i.e. whitelist/blacklist) > >> - or after the initialization (e.g. user config) > >> > >> We need to answer 4 questions: > >> 1/ what are the separators (comma, colon, etc)? > >> 2/ how to distinguish a device identification from a configuration? > >> 3/ what are the mandatory parts? > >> 4/ what can be the optional properties? > >> > >> 30/11/2017 08:35, Yuanhan Liu: > >>> What this patch proposes is to use "name[,mac]" syntax. "name" is the > >>> PCI id for pci device. For vdev, it's the vdev name given by user. The > >>> reason "mac" is needed is for some devices (say ConnectX-3), 2 ports > >>> (in a single NIC) have the same PCI id. > >> > >> Based on the feedbacks we had, I suggest a syntax where everything is > >> optional key/value pairs, and split in 3 categories: > >> - bus (pci, vdev, vmbus, fslmc, etc) > >> - class (eth, crypto) > >> - 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 > > > >> Between categories, the separator is a slash. > > Why is a '/' required as a separator? Are you expecting the key in > key,value pair to duplicate across categories? We need to separate categories because each category is parsed by a different parser. The first level parser will get strings for each category and will call the appropriate parser (by going through different levels of bus parsers for bus and driver categories). > >> Inside a category, the separator is a comma. > >> Inside a key/value pair, the separator is an equal sign. > > sounds reasonable to me. > > >> > >> It may look like this: > >> bus=BUS_NAME,id=BUS_ID/class=CLASS_NAME,dev_port=PORT_NUM,mac=MAC_ADDRESS/driver=DRIVER_NAME,driverspecificproperty=VALUE > > If I take cue from fslmc and dpaa bus: > > for fslmc: bus=fslmc,id=dpni.1 > bus=fslmc,id=dpsec.1 > for dpaa: bus=dpaa,id=fm1-mac1 > bus=dpaa,id=dpaa-sec1 > > So, at least from fslmc/dpaa perspective, above fits. > > Just want to highlight: in some cases the device names can contain ',' - > but then, that can be handled at bus scan level. > For dpaa bus, the device identified from platform identifiers contains a > longer ',' separated string - which is then stripped to form a name like > 'fm1-mac1' before being added to device->name. > > >> > >> A device is identified when every properties are matched. > > So, a ovs-dpdk user would have to know a dpdk bus to identify a device > to plug into a OVS bridge? Yes, the user must know the bus if using a bus id. But he can use another kind of id like the MAC address. > >> Before device is probed, only the bus category is relevant. > >> For the simple PCI whitelist, it means moving from > >> -w 0000:01:00.0 > >> to > >> -w bus=pci,id=0000:01:00.0 > > OK > > >> It is possible to mix some settings in these devargs syntax if the keys > >> are differents. Example: mac= is for identification by MAC, whereas > >> newmac= would be for specifying a MAC address to set. > >> > >> Agreement? > > in principle, yes. > just need clarity on '/' as a separator. Thanks for reviewing.