From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shreyansh Jain Subject: Re: standardize device identification Date: Fri, 22 Dec 2017 12:31:03 +0530 Message-ID: <023a90af-bfcd-328d-4ed9-783ee76203fd@nxp.com> References: <1512027330-30030-1-git-send-email-yliu@fridaylinux.org> <1743809.pZtjZi6UOT@xps> <7044959.u7szEIarlR@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: Yuanhan Liu , Adrien Mazarguil , Ciara Loftus , Kevin Traynor , , To: Thomas Monjalon , Return-path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0046.outbound.protection.outlook.com [104.47.32.46]) by dpdk.org (Postfix) with ESMTP id 72FDA1B33C for ; Fri, 22 Dec 2017 07:47:11 +0100 (CET) In-Reply-To: <7044959.u7szEIarlR@xps> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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? >> 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? >> 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. > > Yuanhan is proposing to use this syntax in OVS option dpdk-devargs: > https://mail.openvswitch.org/pipermail/ovs-dev/2017-December/342273.html > > Please, any feedback or approval that this syntax is good? >