netdev - Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 23 Mar 2018 15:59:35 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com,
        jakub.kicinski@...ronome.com, mlxsw@...lanox.com,
        vivien.didelot@...oirfairelinux.com, f.fainelli@...il.com,
        michael.chan@...adcom.com, ganeshgr@...lsio.com,
        saeedm@...lanox.com, simon.horman@...ronome.com,
        pieter.jansenvanvuuren@...ronome.com, john.hurley@...ronome.com,
        dirk.vandermerwe@...ronome.com, alexander.h.duyck@...el.com,
        ogerlitz@...lanox.com, dsahern@...il.com, vijaya.guvva@...ium.com,
        satananda.burla@...ium.com, raghu.vatsavayi@...ium.com,
        felix.manlunas@...ium.com, gospo@...adcom.com,
        sathya.perla@...adcom.com, vasundhara-v.volam@...adcom.com,
        tariqt@...lanox.com, eranbe@...lanox.com,
        jeffrey.t.kirsher@...el.com
Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and
 common phys_port_name generation

Fri, Mar 23, 2018 at 02:43:57PM CET, andrew@...n.ch wrote:
>> I tested this for mlxsw and nfp. I have no way to test this on DSA hw,
>> I would really appretiate DSA guys to test this.
>
>Hi Jiri
>
>With the missing break added, i get:
>
>root@...-devel-b:~# ./iproute2/devlink/devlink port 
>mdio_bus/0.1:00/0: type eth netdev lan0 flavour physical number 0
>mdio_bus/0.1:00/1: type eth netdev lan1 flavour physical number 1
>mdio_bus/0.1:00/2: type eth netdev lan2 flavour physical number 2
>mdio_bus/0.1:00/3: type notset
>mdio_bus/0.1:00/4: type notset
>mdio_bus/0.1:00/5: type notset flavour dsa number 5
>mdio_bus/0.1:00/6: type notset flavour cpu number 6
>mdio_bus/0.2:00/0: type eth netdev lan3 flavour physical number 0
>mdio_bus/0.2:00/1: type eth netdev lan4 flavour physical number 1
>mdio_bus/0.2:00/2: type eth netdev lan5 flavour physical number 2
>mdio_bus/0.2:00/3: type notset
>mdio_bus/0.2:00/4: type notset
>mdio_bus/0.2:00/5: type notset flavour dsa number 5
>mdio_bus/0.2:00/6: type notset flavour dsa number 6
>mdio_bus/0.4:00/0: type eth netdev lan6 flavour physical number 0
>mdio_bus/0.4:00/1: type eth netdev lan7 flavour physical number 1
>mdio_bus/0.4:00/2: type eth netdev lan8 flavour physical number 2
>mdio_bus/0.4:00/3: type eth netdev optical3 flavour physical number 3
>mdio_bus/0.4:00/4: type eth netdev optical4 flavour physical number 4
>mdio_bus/0.4:00/5: type notset
>mdio_bus/0.4:00/6: type notset
>mdio_bus/0.4:00/7: type notset
>mdio_bus/0.4:00/8: type notset
>mdio_bus/0.4:00/9: type notset flavour dsa number 9
>
>This is on a board with a DSA cluster of three switches. Some of the
>switch ports are not connected to anything, so are plain 'notset'.

Okay. That looks fine. I wonder if it would make sense to have another
flavour for "unused" ports.


>
>What is the "number X" meant to mean?

That is basically front panel number for physical ports. It is used for
generating phys_port_name. It should have separate numbering for cpu
ports and dsa ports most probably. Although, since they have no
netdevice associated, the number is not used and only shown here.

In case of mlxsw switch port 1, the netdev name is then
for example: "enp3s0np1".