From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f68.google.com (mail-pg0-f68.google.com [74.125.83.68]) by dpdk.org (Postfix) with ESMTP id 32C9B7CB6 for ; Thu, 30 Nov 2017 18:16:00 +0100 (CET) Received: by mail-pg0-f68.google.com with SMTP id g7so3256995pgs.0 for ; Thu, 30 Nov 2017 09:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=lEYrhY7eIUd6hz8vb/DkCdF1LCVsfg7i2bJTheGapfw=; b=Ep/ALBfrBOcAjh0UsQQgY7sJqFYcXIGyUsFWLg3F4sunUQ+QSH/f10QPVJjEC/jAFf lV8y2E3gslE1x7G3O24fSJIRy+Brd6S5hsKI/doWrfRQttrSL49edX6MfRGhBr52gtoi J7BKhgJGOtk0YnSu2PsE/+dZ0OfpbojO12rvw+NCS1O4OQK1wQDBvllwrez0qnDNK6DZ G1KukR2OjG6ci4u4SwJOabqmedajgA9NgxlDatWz7GcoSDh3R8SuEMrMMmBv4xjR45Lr e+5lZf728GTUf0WBN7YaeFGNMmXdoeQcZIVXNfpmjXrx0kcdbK03nceZgU+50XdKPS44 JZYw== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=lEYrhY7eIUd6hz8vb/DkCdF1LCVsfg7i2bJTheGapfw=; b=bWylM+WCp92WWToWAxADdxl936AEfDx5vcHDyzkY8L1YMlUWplsv+9GSrsgRmaMAqi YQaMkVZm6kres99sjZP6xkmxBqTJzkX1lTtqkfvgWtF5jCenCAUZD9BO8k4ZZ0ZKvBL8 JwmAqW7W8SCLbxkaB6E8JpB75oDhYv80gdM+kK86fnAAv1yNYxHl94GjFPKBE61tyyNi dLATYkDIL3taO+um4MXO4gRkcrXYldJfZBHKCFyvCXXn15w/OnIUVCl0Ii6sN7gT0dS/ 3LPDaM6jyvqYfaHt7wHrl25nFYPoX5co+ccbS7xa0y0HbcSux8EYBjagIjR2rSwx661C n+og== X-Gm-Message-State: AJaThX6LnD44i3V1qV62Tt9nVTpReKpQU6ZiD5ecI0Gx+S0ZeIH/3poF UF7C5tMXeRzOxkCEDZyYZr7P+A== X-Google-Smtp-Source: AGs4zMbgHn/Wp24dTzIkVv1LIPNE4dhhHMORrkr3MYbjs2XQRhXzyApNv4hY9DyghKuZphdBWRgYaA== X-Received: by 10.99.116.17 with SMTP id p17mr2940861pgc.385.1512062159348; Thu, 30 Nov 2017 09:15:59 -0800 (PST) Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240]) by smtp.gmail.com with ESMTPSA id w9sm8772958pfk.16.2017.11.30.09.15.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 30 Nov 2017 09:15:59 -0800 (PST) Date: Thu, 30 Nov 2017 09:15:52 -0800 From: Stephen Hemminger To: Yuanhan Liu Cc: dev@dpdk.org, Thomas Monjalon , Adrien Mazarguil , Ciara Loftus , Kevin Traynor Message-ID: <20171130091552.3aa6e46c@xeon-e3> In-Reply-To: <1512027330-30030-1-git-send-email-yliu@fridaylinux.org> References: <1512027330-30030-1-git-send-email-yliu@fridaylinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] [RFC] ether: standardize getting the port by name 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, 30 Nov 2017 17:16:00 -0000 On Thu, 30 Nov 2017 15:35:30 +0800 Yuanhan Liu wrote: > The ethdev name is taken from the "name" parameter from the helper > function rte_eth_dev_allocate(name). The name is given by the caller, > thus, there is no way to guarantee all the callers will follow the > same syntax, leaving us the port name is not standardized. > > For example, for all ports probed by the generic pci probe function, > the name is set to the PCI id. For all others, it's set by the caller, > aka, the PMD driver. Taking mlx PMD driver as the example, it's set > to something like "mlx5_0 port 0". > > Unfortunately, ovs-dpdk uses such name for referencing a specific port. > Since there is no standard, user has to figure out what is the right > name for the nic he is using. That adds extra (unnecessary) obstruction > to users. > > Thus, the name should be standardized. We should give user a consistent > interface for finding a specific port. > > 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. > > There are 2 reasons I didn't make "mac" mandatory: > - it keeps the compatibility > - in most cases, the pci id is good enough to identify a port > > However, while writing this commit log, I think it might be better to > use something like UUID for standardizing the port name. This way, we > will always have a very consistent naming, no matter whether it's PCI > device or vdev device and whether a PCI devices has 2 ports share the > same PIC id, or something we have considered so far (say, few ports > sharing same PCI and mac address :/). > > It's also simpler and cleaner. The only drawback is such ID is meaningless > to human. > > Please also note that this patch just comes up with an API to query > a port from standard name suggested above. The ethdev name isn't really > standardized here. This patch is asking for comments after all. > > Thoughts? > > Cc: Thomas Monjalon > Cc: Adrien Mazarguil > Cc: Ciara Loftus > Cc: Kevin Traynor > Signed-off-by: Yuanhan Liu Some thoughts. 1) Not all devices are PCI; look at recent VMBUS 2) The name may have to be set before MAC address is determined on boot. 3) The names themselves are not persistent or human friendly. This is hard see the effort udev goes to.