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 60F84A00E6 for ; Sat, 18 May 2019 08:03:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5B32B2BA5; Sat, 18 May 2019 08:03:28 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 744422B9D for ; Sat, 18 May 2019 08:03:26 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2019 23:03:25 -0700 X-ExtLoop1: 1 Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga005.jf.intel.com with ESMTP; 17 May 2019 23:03:25 -0700 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 17 May 2019 23:03:24 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 17 May 2019 23:03:24 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.129]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.18]) with mapi id 14.03.0415.000; Sat, 18 May 2019 14:03:23 +0800 From: "Wang, Haiyue" To: Stephen Hemminger , "dev@dpdk.org" Thread-Topic: [dpdk-dev] Instability of port ids Thread-Index: AQHVDOD3WKnJlkPEBEeJmJKUQppbZaZwZDbA Date: Sat, 18 May 2019 06:03:22 +0000 Message-ID: References: <20190517114640.31e1e234@hermes.lan> In-Reply-To: <20190517114640.31e1e234@hermes.lan> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZGY3Y2Y2MGYtYzg2NS00NjEzLWFmNDQtZGNmMjE1YWU0YjkwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiVGNPRmpsaXBkYVdyeUpyQzRvTllzN29rTDZLb1pzazRSOHd3eTNiY01tTmpoazQ2V3hmYXh1SFpjUmZ0QTAzVSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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" > -----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 >=20 > Several customers have reported similar issues with how the owned/stack d= evice model > works in DPDK. With failsafe/tap and VF or netvsc and VF there are DPDK p= orts which > are marked as owned and therefore not visible. >=20 > The problem is the application has to guess and workaround these port val= ues in > the port mask that gets passed in on command line. This means a working a= pplication > has to modify its startup script to run on Azure. Worse the actual port v= alues > change based on the number of NIC's configured. >=20 > Overall this is a nuisance for users. The whole DPDK port index concept i= s a bad > design. In Linux/BSD there is ifindex, but few applications care, they al= l use names > which is better. Very very few application care that eth1 is ifindex 4. >=20 > The whole assignment of ports is a mess as well since it is based on prob= e order > and that is based on PCI order, and not anything dependable. It gets wors= e with > command line arguments, vdev, owned devices etc. >=20 > All I can think of is that: > * DPDK network devices need to have human readable names. current PCI i= s not good. > * The names need to be repeatable/persistent. udev names are probably b= etter 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 preferr= ed 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_N= AMES.md https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id= .c