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 8AC97A05D3 for ; Sun, 19 May 2019 20:42:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8E5EC2E8F; Sun, 19 May 2019 20:42:42 +0200 (CEST) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by dpdk.org (Postfix) with ESMTP id 8AA3A1B53 for ; Sun, 19 May 2019 20:42:41 +0200 (CEST) Received: by mail-lf1-f52.google.com with SMTP id n134so8634642lfn.11 for ; Sun, 19 May 2019 11:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinite-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nwd/JXWh6ANVj9jDrehkOs719TKoZ1+ZKSYR+fH8h2k=; b=fOOxZQuk5xt7cuuLHs1GPNhdsWyLEQtjhpL3L9/pFHJ9KVDzp9gNl8jl4OmI5GzmLf umetjyiJP9XkIahsdYvMkP4AWXMp1mNX0Ewzsm4OguSUIdfNEaHyjvodFsa0HrtoSM5V 8/ccKntIAfeImmZAe9oD8+3HOzQAadvND21q7pQ3pIJEO48d30D1AqRrMggzvhoHGGFc 7R284JdpKYrimtvuXZKe1Plp7x+ea4QT5HlOjOjfwyDgaO/DizO52SCU41Ec1MNVc5U8 pWcA9yB/1RQipd4r97s5/nJy7SMi1nBafV9MQKoi5NN2gntV9+FmIoawtGRDO7IjWqr+ gpRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nwd/JXWh6ANVj9jDrehkOs719TKoZ1+ZKSYR+fH8h2k=; b=IQTabdSAiABzEvA7g8akk5GVSvIVavsD01IoWc0HozTYpAIwV10FM0Fn7UBN2Ov2q2 H479WWXJ+EcDZ9BUknTGESkkZyQxobTCwBtYcNHyPVc20bMPMC3AGhW3m89O5UmntW6k AkbtnsqLQmcHnaa2ojicf9tmOJmNB4r6ZLx+W75yRIYkqc0Of8AoIPOhXBzCi3/DexEs NAPo+9TXIUfo3bvDjsdA/vUkvHUjtS6edqb9g+T18b9wFI++CU/IJi8JbPwdBOxrSlBM TvqEzi9r7R2wFls3JmaaHI4Px+KErSXOyK73d9qJODb0c+kMlxAkbcweg2Np5joU3m1c xS6Q== X-Gm-Message-State: APjAAAWqvy5eXv6BnYJ6oDLSTZiTpqBkHP1PTc/JOk25VoMTc+xYXjrG HagkUHMRUFXQTPBu4jqkvko185nkEwnxIgAd4Qot+P3s X-Google-Smtp-Source: APXvYqzVdgAlPBH+4inobQzBjIOAnVjH8FQy6z9HWqXg+NWKpc58CciAavsmQLCC7+gALHKsHbOLoegs0DnUDaJgUL8= X-Received: by 2002:a19:e20e:: with SMTP id z14mr11827701lfg.43.1558291361086; Sun, 19 May 2019 11:42:41 -0700 (PDT) MIME-Version: 1.0 References: <20190517114640.31e1e234@hermes.lan> In-Reply-To: <20190517114640.31e1e234@hermes.lan> From: Jay Rolette Date: Sun, 19 May 2019 13:42:30 -0500 Message-ID: To: Stephen Hemminger Cc: DPDK Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 Fri, May 17, 2019 at 1:46 PM Stephen Hemminger < stephen@networkplumber.org> wrote: > 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. > +1 agree completely