From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f67.google.com ([209.85.218.67]:44567 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752253AbeCXRHd (ORCPT ); Sat, 24 Mar 2018 13:07:33 -0400 Received: by mail-oi0-f67.google.com with SMTP id j143-v6so3912034oih.11 for ; Sat, 24 Mar 2018 10:07:33 -0700 (PDT) Date: Sat, 24 Mar 2018 10:07:27 -0700 In-Reply-To: <20180324160749.GG1891@nanopsycho> References: <20180322105522.8186-1-jiri@resnulli.us> <20180323134357.GG5145@lunn.ch> <20180323145935.GC2125@nanopsycho> <20180323152412.GC24361@lunn.ch> <20180324074551.GD1891@nanopsycho> <0B8BC202-9067-4D34-AC4F-79DC33B4E6F9@gmail.com> <20180324160749.GG1891@nanopsycho> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation To: Jiri Pirko CC: Andrew Lunn , netdev@vger.kernel.org, davem@davemloft.net, idosch@mellanox.com, jakub.kicinski@netronome.com, mlxsw@mellanox.com, vivien.didelot@savoirfairelinux.com, michael.chan@broadcom.com, ganeshgr@chelsio.com, saeedm@mellanox.com, simon.horman@netronome.com, pieter.jansenvanvuuren@netronome.com, john.hurley@netronome.com, dirk.vandermerwe@netronome.com, alexander.h.duyck@intel.com, ogerlitz@mellanox.com, dsahern@gmail.com, vijaya.guvva@cavium.com, satananda.burla@cavium.com, raghu.vatsavayi@cavium.com, felix.manlunas@cavium.com, gospo@broadcom.com, sathya.perla@broadcom.com, vasundhara-v.volam@broadcom.com, tariqt@mellanox.com, eranbe@mellanox.com, jeffrey.t.kirsher@intel.com From: Florian Fainelli Message-ID: Sender: netdev-owner@vger.kernel.org List-ID: On March 24, 2018 9:07:49 AM PDT, Jiri Pirko wrote: >Sat, Mar 24, 2018 at 03:35:09PM CET, f=2Efainelli@gmail=2Ecom wrote: >>On March 24, 2018 12:45:51 AM PDT, Jiri Pirko >wrote: >>>Fri, Mar 23, 2018 at 04:24:12PM CET, andrew@lunn=2Ech wrote: >>>>On Fri, Mar 23, 2018 at 03:59:35PM +0100, Jiri Pirko wrote: >>>>> Fri, Mar 23, 2018 at 02:43:57PM CET, andrew@lunn=2Ech wrote: >>>>> >> I tested this for mlxsw and nfp=2E I have no way to test this on >>>DSA hw, >>>>> >> I would really appretiate DSA guys to test this=2E >>>>> > >>>>> >Hi Jiri >>>>> > >>>>> >With the missing break added, i get: >>>>> > >>>>> >root@zii-devel-b:~# =2E/iproute2/devlink/devlink port=20 >>>>> >mdio_bus/0=2E1:00/0: type eth netdev lan0 flavour physical number 0 >>>>> >mdio_bus/0=2E1:00/1: type eth netdev lan1 flavour physical number 1 >>>>> >mdio_bus/0=2E1:00/2: type eth netdev lan2 flavour physical number 2 >>>>> >mdio_bus/0=2E1:00/3: type notset >>>>> >mdio_bus/0=2E1:00/4: type notset >>>>> >mdio_bus/0=2E1:00/5: type notset flavour dsa number 5 >>>>> >mdio_bus/0=2E1:00/6: type notset flavour cpu number 6 >>>>> >mdio_bus/0=2E2:00/0: type eth netdev lan3 flavour physical number 0 >>>>> >mdio_bus/0=2E2:00/1: type eth netdev lan4 flavour physical number 1 >>>>> >mdio_bus/0=2E2:00/2: type eth netdev lan5 flavour physical number 2 >>>>> >mdio_bus/0=2E2:00/3: type notset >>>>> >mdio_bus/0=2E2:00/4: type notset >>>>> >mdio_bus/0=2E2:00/5: type notset flavour dsa number 5 >>>>> >mdio_bus/0=2E2:00/6: type notset flavour dsa number 6 >>>>> >mdio_bus/0=2E4:00/0: type eth netdev lan6 flavour physical number 0 >>>>> >mdio_bus/0=2E4:00/1: type eth netdev lan7 flavour physical number 1 >>>>> >mdio_bus/0=2E4:00/2: type eth netdev lan8 flavour physical number 2 >>>>> >mdio_bus/0=2E4:00/3: type eth netdev optical3 flavour physical >number >>>3 >>>>> >mdio_bus/0=2E4:00/4: type eth netdev optical4 flavour physical >number >>>4 >>>>> >mdio_bus/0=2E4:00/5: type notset >>>>> >mdio_bus/0=2E4:00/6: type notset >>>>> >mdio_bus/0=2E4:00/7: type notset >>>>> >mdio_bus/0=2E4:00/8: type notset >>>>> >mdio_bus/0=2E4:00/9: type notset flavour dsa number 9 >>>> >>>>> That is basically front panel number for physical ports=2E >>>> >>>>You cannot make that assumption=2E As you can see here, we have 3 >ports >>>>with the number 0=2E >>>> >>>>Look at clearfog, armada-388-clearfog=2Edts=2E port 0=3Dlan5, port 1= =3Dlan4 >>>>port 2=3Dlan3, port 3=3Dlan2, port 4=3Dlan1, port 5=3Dcpu, port 6=3Dla= n6=2E >>>> >>>>The hardware and mechanical engineer is free to wire switch ports to >>>>the front panel however they want=2E That is why we put the netdev >name >>>>in device tree=2E >>> >>>Got it=2E Hmm, so I think that the port number can be made optional and >>>when it is present, it would be used to generate phys_port_name=2E If >>>not, perhaps devlink port index could be used instead=2E >>> >>>So iiuc, you don't really need phys_port_name in dsa, as it provides >>>misleading names, right? Why is it implemented then? >> >>We do need phys_port_name because there are switch configuration >operations, e=2Eg: ethtool::rxnfc which take a port number and queue >number as part of the action to redirect a packet for instance=2E There >is no way to obtain this physical port number other than either knowing >it and hard coding it (not great) or scanning the device tree and look >for the "reg" property value=2E phys_port_name gets you that and it is >easy for an application to scan /sys/class/net/ on startup to get to >know that (and other stuff as well)=2E > >Hmm=2E That sounds like misuse of phys_port_name=2E The original purpose >was >to provide names as they are actually written on the front panel=2E Ok, if we look back at the history of the changes I had implemented ndo_ph= ys_port_id() to return the port number initially, but this was wrong and re= verted based on your feedback, and then ndo_phys_port_name() was implemente= d with your reviewed-by tag: https://git=2Ekernel=2Eorg/pub/scm/linux/kernel/git/torvalds/linux=2Egit/c= ommit/net/dsa/slave=2Ec?id=3D3a543ef479868e36c95935de320608a7e41466ca https://git=2Ekernel=2Eorg/pub/scm/linux/kernel/git/torvalds/linux=2Egit/c= ommit/net/dsa/slave=2Ec?id=3D592050b2541407d033da18226d3644644832d082 https://git=2Ekernel=2Eorg/pub/scm/linux/kernel/git/torvalds/linux=2Egit/c= ommit/net/dsa/slave=2Ec?id=3D592050b2541407d033da18226d3644644832d082 Now that this is reported through sysfs it unfortunately becomes ABI and w= e should not be breaking user applications relying on that and there is at = least one I know of=2E=2E=2E What is an appropriate attribute to use to return the physical port number= within a given switch? --=20 Florian