linux-kernel - Re: [PATCH net-next v2] net: dsa: make "label" property optional for dsa2

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20170110095524.GA1827@nanopsycho>
Date:   Tue, 10 Jan 2017 10:55:24 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel@...oirfairelinux.com,
        "David S. Miller" <davem@...emloft.net>,
        Andrew Lunn <andrew@...n.ch>,
        Uwe Kleine-König <uwe@...ine-koenig.org>,
        Andrey Smirnov <andrew.smirnov@...il.com>
Subject: Re: [PATCH net-next v2] net: dsa: make "label" property optional for
 dsa2

Mon, Jan 09, 2017 at 07:06:39PM CET, f.fainelli@...il.com wrote:
>On 01/09/2017 09:58 AM, Jiri Pirko wrote:
>> Mon, Jan 09, 2017 at 06:42:07PM CET, f.fainelli@...il.com wrote:
>>> On 01/09/2017 08:06 AM, Jiri Pirko wrote:
>>>> Mon, Jan 09, 2017 at 04:45:33PM CET, vivien.didelot@...oirfairelinux.com wrote:
>>>>> Hi Jiri,
>>>>>
>>>>> Jiri Pirko <jiri@...nulli.us> writes:
>>>>>
>>>>>>> Extra question: shouldn't phys_port_{id,name} be switchdev attributes in
>>>>>>
>>>>>> Again, phys_port_id has nothing to do with switches. Should be removed
>>>>>> from dsa because its use there is incorrect.
>>>>>
>>>>> Florian, since 3a543ef just got in, can it be reverted?
>>>>
>>>> Yes, please revert it. It is only in net-next.
>>>
>>> Maybe the use case can be understood before reverting the change. How do
>>> we actually the physical port number of an Ethernet switch per-port
>>> network device? The name is not enough, because there are plenty of
>>> cases where we need to manipulate a physical port number (be it just for
>>> informational purposes).
>> 
>> Like what?
>
>Specifying the physical port number (and derive a queue number
>eventually) for some ethtool (e.g: rxnfc)/tc (queue mapping) operations
>where there is an action/queue/port destination argument that gets
>programmed into the hardware.

Could you point me to a real example? User command?


>
>You already have the originating port number from the interface you call
>the method against, but you also need the destination port number since
>that is what the HW understands.

This is internal to kernel? I fail to understand what you mean exactly.


>
>Aside from that, it is useful for allowing interface naming in user
>space if you don't want to use labels.
>
>> 
>> Why the name is not enough? This is something propagated to userspace
>> and never used internally in kernel.
>
>Because the name is not reflective of the port number in some switches.
>In my case for instance, we have 5 ports that are named after the
>entities they connect to (an integrated Gigabit PHY, two RGMII pads, one
>MoCA interface, and the CPU)
>

Again, I'm missing why you need a portnumber as a Integer to userspace.
>From driver, you can expose phys_port_name:

>0 -> gphy

"p0" or "gphy"

>1 -> rgmii_1

"p1" or "rgmii_1"

>2 -> rgmii_2

...

>7 -> moca
>8 -> cpu
>
>> 
>> Btw, ndo_get_phys_port_id does not give you number, but arbitrary binary.
>
>It's not entirely arbitrary for DSA switches since the port number is
>stored in an u8 whose value is the port number in hexadecimal (as shown
>by sysfs at least).

In mlxsw, we also have port number stored in u8. It is used to
communicate with hw of course. But outside the driver, this is exposed
as phys_port_name "pX".