[dpdk-dev] Instability of port ids

Wang, Haiyue haiyue.wang at intel.com
Sat May 18 08:03:22 CEST 2019

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Saturday, May 18, 2019 02:47
> To: dev at 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 ?

More information about the dev mailing list