From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id CAF16A00E6 for ; Sat, 18 May 2019 15:33:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9B9B42B89; Sat, 18 May 2019 15:33:23 +0200 (CEST) Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by dpdk.org (Postfix) with ESMTP id 0359E2B86 for ; Sat, 18 May 2019 15:33:21 +0200 (CEST) Received: by mail-pf1-f181.google.com with SMTP id s11so5020183pfm.12 for ; Sat, 18 May 2019 06:33:21 -0700 (PDT) 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=eQy5zBfB/ql0AyuDNLcqrMjYNufwymgAos3x+eQ+kkY=; b=zpNMggqDyA8sma1Nn0tLunM9l69+ley1S+D1QbUiTgsa/uGxAD8pHJCYSqvBIpHSPf bqbEHQ4q+7f3U2MmEtF4teqGeTwSnGXyk1I6P5wUv2cH8xnShGQqitCJ02O5s+VtB2ll TwaCs3KQdd95Hn99OHhisYt3qN0tS03onZib6BsuDHFzFuW3gsnE3S4TCoaNehiEcEWl U9gihXLl+Z2NQgYoB76trrS2Xx3mB73duMDvxNr3ToGKijNOdKR9c3VGapCbbbxFSwaS xX8Zmmr1xmaUH8DNuPolLb3pKA049YNyLYL3iC4rk/YpvKBc6dNbZr5spCWTvHwEoOWZ bsRg== 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=eQy5zBfB/ql0AyuDNLcqrMjYNufwymgAos3x+eQ+kkY=; b=KBXH4rfTEBzh3SrHGWbolvsj/edTHB0SXB/q8DVbtRAc1qQ1GhPEdq48uGadFb5YLa lE0acZqPqMqtWOxdfJSpV+Y3Y41r/FkCuXSlEbL0LtoTkgpuA7jXalJFMfWqc0Zk8rP7 Lu9SBCVQ0ebmeG6Gt6Cuw/x1qMKwkdpW8QKhpz8QpfNQvkSF29dvy+22wnMNNrWdRpGI x3O9b3GVZQTkVwJ3qe8XKOZ/R6WG3mb8ACqA+Tuhr46TWkgXYW8BhqNCiL4K7etuE0h+ ui3M71KT0SV+ZIi5KG4nQIdzKjU51PAU3N0WSVFYfN7z23bSdbkH9DvKzrEsl8MNIZaT r0QA== X-Gm-Message-State: APjAAAU3q8vhEqZelmGvLxRqUCjnyps4xKRL4ztfGNpgLdBV0QtCi3NH uA/k2XOO9f5fB+b3R2fGSyq/Jg== X-Google-Smtp-Source: APXvYqxLgRBCIQu0JKVeqYYEfBmiaCzWqk6rKb1jlgjzJlR4Ihi74RwTpdan78ICvcySiG5pbrxnGA== X-Received: by 2002:a65:6145:: with SMTP id o5mr62988219pgv.262.1558186400981; Sat, 18 May 2019 06:33:20 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id r9sm22176854pfc.173.2019.05.18.06.33.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 18 May 2019 06:33:20 -0700 (PDT) Date: Sat, 18 May 2019 06:33:19 -0700 From: Stephen Hemminger To: "Wang, Haiyue" Cc: "dev@dpdk.org" Message-ID: <20190518063319.7b05bdf3@hermes.lan> In-Reply-To: References: <20190517114640.31e1e234@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Instability of port ids 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sat, 18 May 2019 06:03:22 +0000 "Wang, Haiyue" wrote: > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > > Sent: Saturday, May 18, 2019 02:47 > > To: dev@dpdk.org > > Subject: [dpdk-dev] Instability of port ids > > > > Several customers have reported similar issues with how the owned/stack device model > > works in DPDK. With failsafe/tap and VF or netvsc and VF there are DPDK ports which > > are marked as owned and therefore not visible. > > > > The problem is the application has to guess and workaround these port values in > > the port mask that gets passed in on command line. This means a working application > > has to modify its startup script to run on Azure. Worse the actual port values > > change based on the number of NIC's configured. > > > > Overall this is a nuisance for users. The whole DPDK port index concept is a bad > > design. In Linux/BSD there is ifindex, but few applications care, they all use names > > which is better. Very very few application care that eth1 is ifindex 4. > > > > The whole assignment of ports is a mess as well since it is based on probe order > > and that is based on PCI order, and not anything dependable. It gets worse with > > command line arguments, vdev, owned devices etc. > > > > All I can think of is that: > > * DPDK network devices need to have human readable names. current PCI is not good. > > * The names need to be repeatable/persistent. udev names are probably better than anything so far. > > Or bsd style names but they end up being device dependent. > > * The API to get from name to port needs to easy to use and the preferred method. > > * All examples and documentation should avoid using port index directly. > > You need port for fast rx/tx but setup should be by name. > > idea from system like enp24s0f0 ? > https://github.com/systemd/systemd/blob/master/docs/PREDICTABLE_INTERFACE_NAMES.md > https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c > The other suggestion is to use an algorithm like VPP which generates TenGigabitEthernet0/2/2